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FOREWORD 



I 

The United Spates Army Research Institute for the Behavioral and 
Sodial Sciences (ARI) engaged the .Northwest Regional Educational Laboratory 
under contract DAHC19-78-C-0042 to -assist PLANIT authors in writing team 
.lesson scenarios. Needed was a set of recommended modifications to the * 
PLANIT language and a detailed set of authoring 'guidelines. 

PLANIT, or Programming Language for Interactive Teaching, is a. portable, 
timesharing computer software system and authoring language used for the 
preparation and delivery of computer-assisted instruction (CAI). 

Charles Frye spearheaded this effort of assisting conventional, PLANIT 
authors to become "team" authors. 

This Research Report is a comprehensive study of modifications of 
the conventional PLANIT language' and' ife a Complement tcr Research Report 
1286, "Converting PLANIT Lessons to Enhanced Format," by Charles Frye. 
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BRIEF 



t 



This Research Report: discusses several efforts' which were undertaken 
to assist PLANIT, authors in th$ writing of tpam lesson scenarios, N It *Lso 
describes": a^d illustrates the assistance given, to* two such authors who were 
engaged in team lesson dev^lppmen't pursuant tcf a contract between, the 
United States Army Research Institute, and Sensors, Data %n Decisions , Inc. 
SDD is the prime contractor fa£ whom this work ha*s t?een done under a 
subcontract arrangement, * m "~\ ^ 



The text of the document first sets forth a definition of team training 
hich is meant to be a frame of 'reference, for. the authoring features later, 
iscussed. * After .this* .several specific authoring strategies are presented 
igh enabled the kind of lesson presentation desired by the SDD authors.* 

A demonstration lesson is described which was developed to quickly 
srraw PLANIT team training concepts.-. The rationale • for the lesson is v 
dCTcribedi in the text and the lesson itfcelf is ai;ta % ched in the appendix. 

Two other important^ products of the effort are alsb contained in 
the\ appendices^ One is a se*t off recotnmend^d"*afedif icataons to the PLANIT* 
language which is designed to^simplify the *±$am authoring prpcess. Ttie 
^ther is a detailed set of authoring guidelines which/ should help conven- 
tional PLANIT authors to become "tefem" authors/. 
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Introduction 1 V 

/ ^# ■ 

The United States Amy Research Institute (ARI) engaged Sensors, Data, 
Decisions, Inc. (SDD) under contract DAHC19-767C-0042 to develdpy computer- , 
assisted instruction that 'trains teams of tactical data* system users. The 
overall objective of the work was to produce the requisite instructional 
.strategies for computer-a'ssisted team training and .to construct and implement 
a "brassboard" system for conducting an on-line verification of the approach. 

'In pursuit of these objectives, SDD prepared lesson scenarios in a 
computer language called PLAN-IT (Programming language for Interactive' 
Teaching). PLANIT has been used extensively by -the Army in applications 
which require the installation of a CAI software systpm in an operating 
tactical datsl system environment. 'Termed "Embedded Training," the concept 
of utilizing the tactical^ hardware itself to automatically dispense and * 
supervise the training has been promoted by ARI for several years. Thus, 
prospective tactical' operators vould be trained by the' equipment they are 
expected to learn to operate', via the same communication devices that they 
will eventually use in their duty station assignments. 

% PLANIT has been an "effective CAI software vehiple for this training 
due to its machine independence and its extensive repertoire of authoring 
~ f S^Xurej^^gu^ pe r f Qpaance 

records are kept automatically. 1. Since PLANIT had beenu developed with public 
funds,. it was readily available for this *jiew application at ho* additional 
"expense to the .government . However", PLANIT was oriented exclusively toward 
individualized training applications. Since tactical training needs also 
^compassed the training of "terms, *\ a feasibility study^was 'launched to 
determine PLANT'S utility in this regard, V^d to add some experimental 
authoring capabilities to the -system which would permit further exploration 
of this particular application. That work was conducted by the Northwest 
Regional Educational Laboratory (NWREL) under* contract number DAHC19-76-C-0008 
resulting, among other things, in a modification to the PLANIT system which 
would enable the authoring of experimental team lesson scenarios. * 

>> • > 
,SDD use,d-the modified PLANIT in wjh to author their experimental 
team fire missipn training scenarios. Vfhis work is 'Being reported separately. 
However, since the work was novel, new authoring strategies h^d to be 
devised in-order to make the PLANIT lessons .execute ifi th'fe desired. fashion 
using only the primitive team features which had been added. NWREL provided - 
consulting during the ,e£rly stages of this ef fort^ to help work out some of • ' 
these authoring "problems. . * * 



1 ' ' ' ' 

Frye',,C, H. 'The ^gasittiHty of Adding Graphics $nd Team Training Support 

• to PpANIT, Final Report, ARI Technical Report TR-77-A27, December -1977*1 



It became obvious as. the work progressed that the consulting experience 
'would give NWREL the information to provide two important services relative 
to the Embedded Training effort* They arenas follows: 

1. To recommend" a much more "comprehensive •authoring modification 
to the' PLANIT system which would ameliorate authoring problems 'similar to 
those faced by^Dp, and / 

would explain- how to 
earn lesson strategy 



" ^2y / io prepare a set .of authoring guidelines which 
apply the authoring conveniences to a-wide sample of "t 
needs* ; n . V * 



Wit'h these mandates in view, ARI negotiated an amendment ta the SDD 
contract; which provided funds for a subcontract to NWREL, making the pe.riod 
of performance coincide with the remaining time' on tt*e SDD contract for. ,<^\ 
maximum overlap. and continued mutual exchange of information^ Therefore., 
the NWREL statement pf work- consisted . of the above two points, plus the „ ' 
development of a brief demonstration 'PE&NI'F 1'esson whicH would be suitable 
for communicating the concept of. tea'm training within a very short period of 
time (,such as, in connection with briefings at ARl). s 

In, reporting the'results of this .present effort, this document includes 
a* conceptual statement defining the nature of team training and its require- ^ 
ments, and a discussion of the problems encountered in the SDD authoring 
process and the procedures devised to solve the problems for the short term 
(i.e., within the limits of the present PLANIT system). \ 

The appendices contain the remaining, contract report, including a 
set of recommended changes to PLANlt in or*der to implement a more compre-* 
hensive team authoring facility, guidelines for team authqring, ai^d A fcopy 
of the lesson scenario and sample run for the. demonstration lesson^ mentioned ' 
previously. ^ • * \ j 



TEAM TRAINING DEFINEJD 



% The concept of teamwork and-'the team behaviors 
which' are .involved is so nebulous as to elicit a^ 
wide variety of mental images . " Team members might "be 
working side-by-side or separated by great distances. 
They might be engaged in physical work or mental' work * 
or both. They each migh£ be Assigned individual work 
which will later be ^integrated or they might be 
huddled and working together. 

«« • 
~* Th^re -are many reasons for performing an activity 
through testmworlr rather than ori an individual , basis, 
.such as: \ ^ , * v * 

* * * 

• To distribute excessive t energy requirements, 
bringing them within reasonable human limits. 

. • To achieve ^ ^ higher quantity output- than would 
be possible individually. » 

• To accomodate a geographical spread oQcasioned 
by the kind of work being performed. 

, ff 

€ To enable the processing of stimuli which are 
# being received' -too rapidly for an/individual - 

to handle, » * 

^ • To distribute decision making with the intent 

to improve the quality of the decisions through 
a process of consensus. . ^ 

• sTo buil'd itforale * ^ 

Probably nq team effort wiJLl have all of the. 
characteristics. Rather, there are " different kinds of 
team efforts. Even so, there are many ways to\train 
teams. JHoWever, *the objective here is to define what ■ 
is 'me,ant by the kind of team training that characterizes 
the intent of the embedded team graining system described 
in this document. It, turns out that for many kinds of 
teamwork situations, individualized . training will suffice 

Therefore, wfe will examine several typical team 
.models and describe a seemingly satisfactory training 
model for each. Attention- will then *be directed to one A 
of the models* which best characterizes the kind of team 
training*envisioned by th^s effort/, , 



Before entering the discussiofi about particular team 
models, there -are certain observations which will pertain 
to air of them, collectively; It is assumfed that the 
observations pertain to team activity in general, and 
therefore pertain to t^am -rtraiiilng as \vel*. * 



Observation 1/ 



Team' activity b.egins with a con^on 
source of 'supply or information 
such that each o.f -the team member's 
draw from that source. We will call 
that source a Common Data Base^ (CDB) . 



Observation 2 . 



Observation 3, 



Team activity results in a product 
or" a related class of products, either 
of which might be turned out in quanti- 
ties. 

The product might consist pf something 
(or several things) which are manu- 
factured during the team activity or . 
it might consist, of an * update of the 
* * x CDB or bath; 

* 4 x • 

With these three observations as a frame of reference,, 
let's proceed with the discussion' of some team models. 
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Electronic Apparatus Assembly Model 

^ \ 
The inspiration for "this model comes from the familiar 
reports of production methods in certain Japanese* electronics 
factories /- The workers ar^given instruction, in groups and 
individually, regarding the assembly of some particular 
apparatus Ce\g., a television set). This common beginning 
even includes group singing and calisthenics. - The results 
are claimed t& include teamwork, benefits in the production 
of television sets, jetc. 



The pictorial model of this kind of teamwork is fairly* 
simple:- 



CDB, 




Acti^ 
vity 
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Note that §ach vertical path represents the history of 
a' single team member culminating in a product « (P) Ijv this 
riodel, each team ifierabej: produces a ^distinct product* Note 
als<» that the model can be general izied to, a team of any 
size greater than or equal to two -members; 
> * 

*!The training implications for this model do not 
• normally require team features >of the kind that entail 
interaction between -training packages/ Thi6 team is 
essentially a- collection of members who are performing 
individually so their % training (particularly the cognitive- 
or manipulative-type)! can jUst as well be administered in 
individualized ^packages. . . m ' * 



Space Cfraft Assembler-Model , \V ' 

This model differs from the "electronic apparatus 
assembly" model primarily in the unified nature of the 
product. The pictorial representation is' as follows:' „ 



CDB 




Acti- 
vity 
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Note -tl?at a distinguishing characteristic of this 
model is in .the retained identity <3f the contribution of- ' 
eachT team member to the final product. It is possible 
to disassemble* 'the— produet— and recover the {piece that 
each member produced. ' * . % 

Many would be quick tp point- out that tdiis is a 
gross over-simplification of the buildihg.of a space 
craft L that much interaction goes on aftd the data base - 
is continually being updated." * Howev-er^that observation 
would pertain only to corrections in faulty designs (which* 
probably often occur ). ^This model assumes a perfect 
design and a delegation" of tasks to produce components 
which are later to be ^ntefera^e-d into a single operational 
unit. 

•\ - 5 - * • 



Another common example of this model is found in • 
the progr aiming of a large computer software system 
where .each of many Subprograms' is assigned to- some 
individual member of a programming team. The finished * 
product will be an- integration of the individual \ 
efforts each of the members. 

As in the previous model, sin6e the task is being 
performed independently, the training to perform that- ^ 
task can just as well Be^dninistered individually.. 
Therefore, again acknowledging that this iS actually 
a team exercise,, the* nature of the team model^io6s ; not 
require the acquisition of «team behaviors- as a training 
objective. «, - v 



Air frine Reservation Model • { 

* * This model differs ;£rom the previous ones in at 
least two respects: % the product consists of updates 
made to the CDS, and the- product cannot be disassembled 
into components which can be identified with particular 
team members. t ■ 

' The pictorial of this model follows:' . ' t 



A- 




* i J, 



Here, as before, the members are working indepen- 
dently I Of- course we know from experience that the agents 
quickly confer with one another when the computer £o£S 
down. However, when the system is working as, it should, 
thifc model requires no interaction between agents. Thus, 
bepause they do their work independently, they. can receive 
adequate job training through individualized training*' , 
packages. T^aAi behaviors' are not part >>of the learning > 
•goals for the execution of this part of their task. x * e 



This model is, similar to the previous one, adding 
.only ureal time 1 interaction requirement amgng the team 
members during the course -of the activity, ^ts pictorial 
might be represented as follows:* . 




t . 

The operation of this model consists of actual 
team exercises' on actual equipment but with simulated data 
and .with ail aborted .or non-effective product. TJie 
attack is ^ot real (at least in 'the time frame of the 
exercise) Itifd, the guns do not actually fire (or if they 

do 'it is not for ef f ect) ♦ 

* * * * 

The Computer-Based War Games Model has served as 
th$ primary vehicle in the past, together with adjunctive, 
classVoom sessions and reading assignments, to train 
recruits to Operate the various military tactical* systems. 
Typically, simulated, run|f are monitored by a trained 
instructor <and then a debriefing takes place at a later 
time^ perfraps, in N a classroom. ' 

No argument is intended regarding the fact that 
training does take place within the intrp<fuction-simulation 
debrifefing^ paradigsu However, two things shduld be fairly 
obvious about the mse> of the tactical system in this modej^ 
"its" object is not 7 productivity since - the normal:, product of 
the system (firing accuracy) is deliberately aborted, and • 
it is not teaching, it is testing . A novice would be com- 
pletely lost in the system just as one with no previous 
flight training would be completely -lost in si LJNK trainer. 
The -draining has occurtfecT prior to the exposure to the 
equipment and thp simulation work on the equipment tests 
whether the trainee can perform* acceptably the skills which 
have b een taught . / 

■ 13 



Thus, the Computer-Based War Games Model can be ■ 
described as modifying a team- operated production , 
^tactical system by 'eliminating its normal productivity , ' 
•end using it instead as a performance testing device 
which either declares the trainee f s competence'^or^ 
provides data for further remediation and training. 

The training' for this model • requires that team 
behaviors must be learned # along with cognitive and 
manipulative skills. \ However,* at the risk of too much 
. redundancy, 'note that the learning takes place in the •• 
classroom ~or in the books but not, on the simulator. * *' 
The simulator is only providing feedback for the learning 
that should have already occurred. The new learning 
ef f ectiveiiess of the feedback will await the debriefing 
(which could be a comment made at the*moment ^or a later 
session .in a classroom) . 1 "J, 

This last mod§l will complete the progression. 



\ 



Tactical Fire Control Model 



;The pictorial for" this model was implied in the 
discussion for the previous %ne, iramely the same but 
with the addition of a product (which was eliminated, 
from the prior one for simulation purposes): 




/ 
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* Tliis Tactical lire Control Model would seeih to ■ 
incorporate all the- features, of a, generalized* teani 
exercifee,-at Ipast as far as the current state-of-the- 
art has carried it. % Note ;t hat it includes all -of the 
following elements: 

: . ' . \ 

• A common data base (of information and 
* materials) 

• .Differentiated team member activities * * 

Provision for updating the data base 

+ • Required interaction among. team members 

• * * » « 

Common product (components not traceable 
. * to contributing team members) 

e 

t Such a model. as this places, heavy requirements 
on team behavior objectives among ot'hep: performance 
criteria for the training of recruits. To rely solely 
on individualized training packages * (of any kind) Would 
fail 1 to exercise the recruit in some of the skills that 
will be needed to operate the system. 



* x * ,m * • 

Implications of the Models for Team Training 

Ixi all ,but "the* last tfwo models, individualized 
.training packages would seem to suffice. Although 
there/were several instances of team performance, 
the team members were expected to per'form essentially 
non- interacting tasks "which were later to integrated 
into a single product. * " 

However, in the last two there; appears a clear 
mandate for^ addressing tea?i behaviors iji the training. 

In- any caise, v it is generally true that the mdire 
similar the training is to the intended task, the more 
effective it will be. The implications for this are 
quite 'clear, especially where the task in question in- 
volves the operation of a computer: that training can 
-be threaded into - the activity- its elf- and -thus—produce — 
nearly ideal similarities to the expected task. 
Computer-assisted training has established its effec- 
tiveness by now, and. can quite ieasibly be used to 
direct the training in either of 1pHe last three models. 



*In the case of the Air Line Reservation Model, 
the computers-assisted training can* be presented in 
individualized fashion. Several such systems exist *"> 
for this mode of instruction, depending on*the kind t * 
of lesson presentation desired and/ the typfc of equip- 
ment on which-the system is designed to operate. 



r * In the case of the last two models, relating to 
Fire Control Systems, the PLANIT authoring system is 
being modified*, to accomodate the kinds of team 
training requirements which are found to % be necessary. 

'The following .features are presently available or 
planned: * 

/ Scenario authoring and execution facility 

(available) * \ 

t 

• Provision for a Common Data Base (numerical' 
mode available, generalized data capability 
planned) 

( 

m Provision to update the data base as required 
(available) . ^ N 

K • 

•* Provision for acquisition of 'and communication 
among team members ^(available, ; enhancement 
planned^ 

• Provision for the independent and/ or inter- 
dependent execution of team lesson scenarios 
(available, enhancement planned) 

Provision* for manipulating the hardware in a 
manner that will not be distinguishable from, 
the ultimate task (available) 

• Provision for the generation of output data 
which can be correlated to the/intended" system 
product (available) # 

\ 

• There are at least two major limitations \vhich will 
probably be evident but will nevertheless «be stated: 

# -The computer ^cannot- accomodate all of the 

/ . * tactical software' and all of PLANIT at the 

"same time. While training is in prog2?esS^ only 
a segment of the tactical system fcan be dealt \ 
with at' any .given moment. 
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It will* normally not ice practical "to thread 

• . straining in with 'the •activity .of a production ^ 

» fire control. system. There will.be no dxtra 

* time available* to take the operating team 

< member, through Remedial " exercised while, guns 
4 are firingV Ihe exception may -be found in the 
- • critical situations where trained operators . 

' hav§ been* immobilized and novices must step in. * 

In sunmyary, there was an attempt to define team 
training in- term? of a spefeialized kind of requirement , 
for the deliberate, teaching of. team behaviors. Many of 
the tasks which are rightly considered to be team t r % 
exercises do .not -require an interdependent, interpersonal, 
kiftd of* team member performance, -Rather, the elements of 
the team task have been so delegated that the team* members 
can perform their yrork largely independently. For ,thi£ 
kincl of team mfember performance, individualized training 
should be Sufficient. 

However, there are interdependent team tasks, par- 
ticularly amoiig Tactical Fire Control systems, where 
team members must act in concert, where -no one member 
of the team can perform the task satisfactorily unless 
all* members perform satisfactorily. The training for , 
this must include .the teaching^ of t§a*m behaviors. Also/ 
since. the facility is available, there is no better place 
to deliver the trailing ' than on. the system hardware itself 



TEAM SCENARIO PROBLEMS AND SOLUTIONS \ . ' . • 

As already indicated, SDD did their team lesson 
scenario development using a PLAN IT which contained 
only the rudimentary set o* team authoring features, 
including: * * . 

• PUT MATRIXNAME * 

t • FETCH ilAlmiXNAME / 

• DIAL n T MESSAGE. T (Usafble in OKLc) 

• TERMINAL ' , 

SDD personnel had no difficulty learning conven- 
tional PLANIT authoring from the user manuals. sThey 
requested consulting help for the team logic. This 
was provided in the' form of one on-site visit and 
several exchanges over tfte^ telephone. In addition, 
several section? of scenario were coded for them, 
either to use as "it was, or to provide a model which 
they could -modify to their needs. 



9 Initialization ' , 

• c 

Initialization is taken to include the initial 
gathering of the team members onto the t.eam lesson, 
♦providing suitable points in' the lesson logic where 
necessary data initialization could occur, 'and making 
possitrle a debriefing and re-initialization for the - 
n.ext team. 

The cod£ provided to SDD was taken from the example 
in the Feasibility. Study ''report . 2 Some modification of 
this example was necessary to adapt it for two-perspn 
teams and to provide re-initralization logic. Also^ 
a different' COMMON Matrix -size 'was desired. The 
code provided for this task follows: 



Ibid ; p. 5$>" 
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FRA^ME 1.00 l(D. ) 

1 * v 

G2. CRITERIA s 
C:SET MATRIX(X,10,4,2) 
IF LINK (9) NQ 0 C:PUT X C:LINK(9)=0 
ELSE C:LINK(9)=1 C: FETCH X 
IF PROD X(1,3,I) F0R(I=1,2) NQ 0 
F: SORRY, ALL POSITIONS ARE TAKEN. TRY 

FRAME 1.50 (Q. ) 

G2. TEXT 

ARE YOU FDO OR FDS? 

FRAME 2.00 (Q) 
» 

G3. ANSWERS * * 
0 KEYWORD ON 
A FBK) ^ « 
B FDS 

G4. ACTIONS 
A C:SET COLOR=l 
B C:SET COLOR=2 . 

- R: ANSWER ONE> OF THE TWO' OR TYPE FINISHED' 

FRAME 3.00 (D) 4 

G2. CRITERIA 
C: FETCH X 

IF X(l,3.,COLOR) NfQ 0 . . , 

F: SORRY^liiE HAVE ONE OF THOSE ALREADY. CHOOSE ANOTHER. B 
.ELSE cTSET X(l,3,COLOR)=TERMltiAL C:PUT X B:5 

" : " ^ - 

FRAME '4.00 (Q) " 

02 . TEXT " ' < . I , • • 

DON'T HAVE ALL THE PLAYERS YET. TYPE 'GO* TO CHECjU&GAIN. 

G3. ANSWERS ± ' * 

A 'GO ' , ; 

FRAME 5. 60 (D) ] 

G2. . CRI-TERIA * • * 

C: FETCH X . » ' •* 

JF PROD"X_(l,3,I) FOR (1=1, 2) EQ 0. B:4 

'ELSE C:LINK(9)=0 F:OK, LET'S GO. B: FDO, FDS; COLOR 

J > . ' - » 



V 



FRAME 6:0(J (Q) • § 



G3 .^ANSWERS -J 
0 WAIT 10 s t ft 
A DEBRIEF 



G4. ACTION^ '.' 
-» C; FINISHED 



Hi' 5 



SS. 

FRAME 7 .00- (P) i;, 



0 



i » 

G2. STATEMENTS \ 
F: DEBRIEF AND RESET} 
C:SET MATRIX(X,10',4,,2) C:PUT X 



I 

i 



* Most of the logic in the abo^ example is similar, / 
enough to previous examples that fto further explanation 
is needed. However, a couple of things will be pointed 
out. . 5 , l\ „ V 

v Note the second and -third lesson line of Frame 1.00; 
whfere the LINK logic appears. These two lines ^will cause 
♦the Common Matrix to ber initially' defined on the first 
execution of the lesson. / f 

Next, note that the last line of Frame 1.00 terminates 
with a branch to Frame 6*00. Under formal student conditions 
if all positions are indeed occupied, the branch -to Frame f 
6.0Q will simplv^activate a ten second waiting period 
after which that student will be logged off. However, 
the author will know at that point that the word, "PEBRIEF" 
•can.be typed during the ten second interval which will 
cau^p Frame 7. 00 to be executed. * It was intended that % 
SDD would add code to xjause any values of interest to * • 
be printed in Frame 7.u0, after'which the Common Matrix 
would-be re-initialized in preparation for the next team. 

Comparing the* above example with the initializatipn 
example in the ^Guidelines (in Appendix B) , one will find 
a marked simplification due to the additional authoring 
directives. Not only is the code simpler, it is also, 
foore effSfcrtive-in that^ the * PLANIT system makes tfte dete**- 
mination wh ether th e tea m is /together and when >to let 
the students proceed. Efficiency is also improveiT'By , 
an order of Magnitude. It is no longer necessary for 
a particular student *s lesson to execute simply to deter- 
mine whether, that student should be allowed to proceed. 
Rathe?, that student is not scheduled until conditions 
ft&ve been met. 



Synchronization -* I 

the SDD-l&ss^ne wejre prepared for two-member teams- 
,where*-the members were' 'designated the -"FDO" and "FDS", 
respectively. \, ' 

/ *• . . " > >, 7 

* ^The synchronization requirements followed a regular 

pattern throughout the series of- lessons, described by 

the following steps: 

** «. • 

„ Step 1: 'Fire mission options presented tcPWth the 
FDO and FD3? * 

Step 2: FDO chooses an option wh^i*e the FDS waits. 

Step 3: FDS is* informed- of FDO ' s ^choice* while/*FBO 
/ - movfes on to the next fire mission oplpon 

list. \ . * t ■ . , y ' 

* Step 4: FDO wafts to £nter next optiojn while' FDS 
t ' enters previous option. " ^ 

* ** 
Step 5: FDO en.tei^ next option as the cycle repeats 

* f. * 

Thus, the FDS is held exactly one move behind the FDO, 

moving stogether ^ih^this fashion throi^gh the scenario. 

One variation to .this pattern allpwed the FDO to v 
move to independent execution of another scenario 
while, the FDS proceeded alone through the titer missibit 
scenario without the interaction with the FDO. 

The synchronization algorithm devised* for tl^isr ,* 
requirement made use of the PLANIT Common, matrix, DIAL 
command, WAIT directive, , and^a synchronization code • 

• number scheme: The* Scenarf o#for the "FDO and EDS w^re 
similar but not 'identical. * 

<. * ^— © 

The FDC) 'executed a normal PLANIT Question frame 
.wherein an option list was presents and one of th^/ 
options (by number) was given as the response. .< 'Then, 
instead Qf allowing execution' to move from one Question 
framfe to the £ext; execution always branched after*, each 
of t he Q uestion frames to a set of c ontrol , fr ames/ therh, 
/* back to the next Question frame in t-he sequence/ The # 
Question frame sequence, was designated by frame nuihbprs 
in .an array called SYNG, where each synchronization, code- 
number value, whdn us'ed as a subscript to the SXNG. array, 
'designated the appropriate next frame 4n the sequence^ 

* Therefore, the synchronization code number, together * # ' 



with the SYNC. array, 'uniquely defined every point of 
progress .through the lesson scenario. The 'control 
frames to implement this algorithm included an- 
initialization frame at- the beginning of, the lesson 
segment, "and. a set of synchronization frames- placed 
within the lesson segment. , " ' ' ■ - 

The initialization frame- contained the .initialization 
logic described in the previous section as well as the 
SYNC ^rray definition % JThe statements for the latter 
were as follows: . • , • 



C-SET MATRIX (SYNC, 60) «- r v 
C:SYNC(l)=ARRAY(9,10 l ll,12,13,14,9L6,17/etc.) — ' + 

> C:SYNC(17)=ARRAY(37,etc.) • 6 . ' < , 

etc. ■ ** , • - 

The' compiete array declaratipn has not been fiUed in 
above (as designated by the "etc.'V; HoweVer.^he numbers 
are the frame number values corresponding to the - f synchron- 
ization code values. For example 7 , a* synchronization code 
value of "17" would show that 'the team is executing frame 
number 37. The PLANIT. logic implementing the synchroni- 
zation follows: \ • " „'--j \ v . 



« 




FRAME 5.00 (D) . ' 9 

' * . ■> ' . ' 

G2.' CRITERIA ff M\ V/o o -, n L i 

C: FETCH X . C: X(l, 3 ,1)=RESP0NSE^ C;X(3,3,1)=X(3,3,1)+1 

C*PUT*X * ** 

IF X<3,3,1J LS X X(3,3,2) B: SYNC (X(3 2) ) 

IF t X (3, 3/1) EQ X(3,3,2) 'B:8 ~. 

ELSE F:@$. ' • 

FRAME 6.00 (Q) 

G3. ANSWERS > . . 

0 WAIT,, 5 

A - DUMMY /- - - . 

a 

G4. ACTIONS 4 
-A F: STANDBY. , 

FRAME -7, 0Q-(I» ' — _, 




G2. CRITERIA - * 

C: FETCH X • * <■ ■ ' 

IF X(3,-3-,l) GR X(3,3,2) F:@$B:6. % . . 



K . - • • ■ - 



FRAME 8. DO (P) \ ^ ' 

*' • .' \ *f. a 1 

G2. • STATEMENTS • \ . 

■"BiMljBffi, M3,M4;M5; X(l, 1,1) ' ' ' ' . 

Ml: DIAL FDST I THINK "PAGE* IS THE' RIGHT ANSWER." B- TAIL 
M2:DIAL FDST I THINK 'FIR*' IS THE\RIGHT ANSWER. B: TAIL 
. M3 : DIAL FDST I THINK 1 CLEAR * IS THE^GHT ANSWER. B* TAIL 
*\M4:DIAL FDST -I THINK" 'CORRECT' IS THE RIGHT 'ANSWER. B* TAIL 
• * M5-: DIAL FDST I DON'T KNOW, THE RIGHT ACTION; YOU CHOOSE- 
. TAIL: • / , - - ' 

FRAME 8.10 (D) . . - 



Q2.' CRITERIA . ' 
B:SYNC{X(3,3,1)) 



Each time the FDO received new fire mission instruc- 
tions in a Question frame,, responded to a list^ of optional 
actions, and received feedback regarding the correct or 
incorrect nature of . the choice, execution would always 
branch to the above set of frames. 

\ * 
^ '« In Frame 5.00, the Common matrix would first be 
updated with' the, value chosen representing the option 
(shown as X(l,3,l)) und an^increase by one of the 
synchronization code, X(3 ,3, 1) . v (The synchronization . 
code for. the FDS w.as *X (3,3,2 )) . The PUT X statement 
marks .the completion of the update. Then a test is 
made to determioevlf the FDO happens to be out-of-step * 
xn the'seenario (as! would be the case if he had beeA 
executing independently); If true, the branch would 
put his execution back in step again, 

^ The next test "X(3,3,1)/eQ X(3^,3,2)i' asks whether 
* the "synchronization codes for the two players are equal, 
i.e. whether ttie FDS is ready and waiting for. the FDO 
■to respond. If true, execution branches to Frame 8 '. 00 
where the FDO's response is DlALed to 'the FDS and 
execution continued at the next frame designated by 
the SYNC array, the branch Lbfcing implemented in Frame 8.10. 
If the FDS is-not ready yet, th| FDO will. wait for five 
second intervals, ea'ch time testing (in Frame 7.00) 
if. the FDS is/ready 7 yet . .. When the FDS is ready, the 

X(3,3,2) code wi ll be advanced hy one, frans-trig T»yp'r»ntion 

for the FDO tO p drop through Frame 7^00 and on to Frame- 
8.00 and beyond. « * : 

In order for the FDO to execute independently in 
another scenario while leaving "the FDS to /proceed | 
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,3,1) synchronization code 
number (e.g. 1000) and 

Frame 5.00 until/unless 
the "team reiatiqnship. 
will be automatically 
be placed back, Into 
FDS simply by branching 

est will put him back into 



in this scenario alone^/ the X(3 
is set to some, arbitrarily high 
branches are no longer made to 
there is a need to re-establish 
Note H&at the team relationship 
re-established and the FDO will 
proper synchronization* with^the 
.to F£ame 5.00 where the first t 
the lesson again. . , 

• The I*DS will -iiave a slightly different synchronization 
sequence because he must wait to receive the FDO message 
befqptf proceeding* -However-, the SYNC array initialization 
in the f irst frarte will be the' Same (albeit with ;dif f erent^ 
f ramft ' numbers) . . \' # . 

For/the FDS sequence, the present at i£n\ of the fire 
• miss ioiTopt ions must be split from the ^response evalu^ 

portion with a branch to the synchronization section V 
^between. - Thus, the SYNC frame numbers will reference 
.-second half, of each of these split framesTj, The patter 
is a.s follows: ) 



FRAME 2.00 (Q) 

■ ^ % 
G2. -TEXT • • " * ' 

This text presents the 'fiate mission instructions and 
the list of options from which t*he FDS chooses. 

" ■■ ' ^ 

^G4. ACTIONS , » * 

B:5 




/ 



FRAME 3.00 (Q) 



G3. ANSWERS 

Answer" matching instructions for the chosen option. • 



G4. ACTIONS . . , 

Feedback pertaining to tlie chosen 'option. 

• O " - < ,: V " 

The above two Question framefe constitute that Which 
would normally occur in one Question frame were it ript . 
-necessary to spli t the sequence to permit synchroniz ation. 



-ttw^wo O.J. y w ^ yj . ■ — ~ — - - — IT J=-=-_-T_ 4 . 

In the above case, the synchronization frames begin 1vith 
Fy^me 5 # (X0 f and the first SYNC entry would be the value , 
"3' L to .^ orregpond to Frame 3 # 00, . 

The synchronization frames for the FDS follow: 



4 
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FRAME -5. 00 (Q) 
G2. TEXT 



J 



G3. ANSWERS ' , 

0 WAIT 1 * 
A DUMMY, 

1 * ■ _ ~ : 

G4. ACTIONS 
C: FETCH X C:X(3,3,2)=X(3,3,2)+1 C:PUT X 

FRAME 6.00 (Q) 

»* . 
G3. ANSWERS 

A £>UMMY * , ■ ' 



G4. ACTIONS 
C:SET REPLY (1) 



FRAME 7.00 (D) 



G2.< CRITERIA 
C: FETCH X - ' ' * 
IF X(3,3,l) LS X(3,3,2) . 
F: STANDBY FOR FDO ACTION BEFORE RESPONDING.. B:6 
ELSE C:USE REPLY $1> B: SYNC (X (3,3,2) ) 1 • 



; Encountering Fi;ame 5.00 causes a very brief pause 
(one second) while the remainder of the text, is printed 
oh the FDS terminal. The "@$" characters serve to 
suppress the 'extra line feed'which would normally occur 
at >that p&int (a special PLANIT authoring strategy ,bu-t 
runreiat^T to teaming or synchronization) . 

V* » * • 

» t- 

In Group 4 of Frame~5,00, the FDS synchronization 
number in the Common matrix is increased by one. Both 
scenarios OFDO and FDS) rely on comparing the current \ 
values of the respective synchronization numbers to 
determine when to alTow. execution to continue^ '-For the 
FDS, Jthis determination is made in Frame 7.00. Note 
* that^the FDS must respond in Frame '6.00 before Frame 7.00 
will be executed. The response iix Fra&e 6.00 will* be 
*to hxe 1 ist of alternative options which had just been 

presented prior to the branch to Frame 5.00. However , _ 

1? the FDS responds too soon (i.e.' before the FDO 
message has been received), the test in Frame 7.00 will 
cause a loop back to Fijfcie 6.00, ef f ectiveljnd.gnoring 
the response, but witlfr the cryptic message toS^ 



/'STANDBY FOR FDO, ACTION* BEFORE RESPONDING."' 

As ,soon as the* FDS receives the proper message ^fronfc 
the FDO f s lesson he enters the optiqn number chosen v for 
*the response to the pluvious displayed option- list. 
That response is immediately placed in PLANIT's REPL#(1) 
.response buffet. Then, in Frame 7.00 M the ELSE * 
"alternative "of the IF statement will be executed (since . 
-the sending of the* FDO message i^ accompanied wit^h 
the appropriate update of synchronization numbers} • The 
ELSE track of the lesson ' scenario designates, that REPLY (1) 
buffer be Used for the next Question frame ^answer evalua- 
tiOn> and the lesson* branches back ,tQ that appropriate 
frame number. % . 

While the foregoing logi^ is not necessarily suit- 
atile> for all lesson syrichronizatipn needs, it does 
satisfy %L1 the requirements for this one. With this 
scheme, synchronization at properly paired points will 
be virtually guaranteed. Yet, jut also allows the two 
members to work independently. 

A variation of the abovej scheme would probably be 
-useful fdr a wide variety of synchronization applications 
but specific lesson requirements would have to be 'known 
in order to • modify the sequence appropriately^ 



Even if the above, logic were t^ be use# fegain just * 
as it is, it woul<k£e usqful to make some single modifi-. 
cations which would eliminate the use of the DIAL 6 - . 
directive, Instead, the chosen-option -number yould be 
passed to the FDS 1 lesson through the .Common matrix 
and used in the J£,DS lesson to select «the corresponding 
message to be printed. 'The results on the terminal 
wauld be identical but the logic of the control sections 
of both lessons would need to be changed*. . There would 
be some improvement in efficiency but, more importan'tly , 
the resulting lessons would be fully, transportable to \. 
the TACFIRE hardware. , 
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DEMONSTRATION LESSON FOR TEAM TRAINING , 

^ 1 ■ 

^A demonstration iesson for team training has been 
reproduced in the appendices. Both the card deck for 
the lesson and a sample run have been included* 

The problems of demonstrating a particular feature 
of any system are' usually quite different f rpm that of 
developing instructions for putting the system to 
practical use. This is particularly true' for a computer- 
Vssisted instructional system such as PLANIT. 

Instruction, usually takes place over a. period 'of + 
time. There is typically some orientation .necessary to 
introduce the "trainees to the material, and then a seq- 
uence of imparting knowledge and assessing performance. 
Instructional sessions often run for an hour or longer 
- and several sessions are often required to reach the 
desired instructional objectives. In terms of the 
lesson, scenario itself, the introductory parts are most 
b^ften composed of the most "elementary examples of 
authoring strategies, thus, for demonstration purposes, 
where time is often limited to 15 minutes or so, the 
lesson^must move quickly, require minimal* orientation, 
and show the deSired operations almost from the beginning. 
Also, it must obviously be interesting arid command 
attention. This helps to explain why games of a 
relatively unsophisticated variety. are so popular for 
demonstration purposes. 

The demonstration lesson developed to show PLANIT f s 
team twining capabilities is such a game. However, it 
has ^lsc><been carefully devised in such a way that 
• partic- psuJts can improve their ability to play the game 
with prkcta.ee.. Thus, some learning takes place. 

The game which was developed ±s modeled after a * . 
real life problem faced by truck rental firms regarding 
*the distribution of their' rental equipment resulting ^ 
from one-way rentals. Many rental routes attract cus- 
tomers much more readily in one direction than the other, 
leading to the possibility of accumulating equipment in 
remote cities where it sits idle. Often, the rental 
firms must provide discfount incentives in order to^get 
* the equipment back to the higher utilization areas again. 
Of course they discount only ehough to entice the customers. 

This demonstration game presents a constrained 
version of that one-way truck rental problem. The operating 
range* includes only 'four cities. From one to eight truck 
rental <> companies compete for available customers who wish to 



\ 



use L he tr uck ov ei— an y one of the. tw elv e po ssi ble route s. 
In addition to priority customers who are willing to ° 
pay full rate to take- the truck, there are also two 
other classes of potential customers, one who frill go 
at a discount ^involving some reduction in profit, and 
another who will go only at the lower rate which results 
in a loss to the company. Each team player governs the 
affairs of one compapty, competing to earn more accumu- 
lated ^profit than the other companies. 

The truck rental game has been devised to provide 
a customer base, which is proportional to tfie size of 
the city and the particular route desired. * All com- 
panies draw customers from the same data base on a first- 
come basis. "The customer pool is replenished at regular 
time intervals where the numbers of replacements „ for 
each possible route are chosen randomly within the limits 
of the expected number for that route.J^ The total number 
*oT customers replenished in any route category is asym- ■ 
totic in that remaining unserved customers tend to 
dimifrish the number of new customers which will be added 
to that category. Thus, the planned effect will be to 
maintain a relative scarce level of profit-making cust- 
omers. (There is no limit to the "freebies M ). 

Another strategy which has been built into the game 
is a period of time that rented 'equipment is out of 
service, i.e. eriroute to its destination. This delay 
is differentiated according to the distance that must 
be traveled. This tends to limit the opportunity to 
capture as many of the full-paying customers as one 
might desire. ^ 

v The game automatically calculates profits according 
to the distance traveled and accumulates profits for each 
player, making a display of all ^companies' profits avail- 
able upon request. Also available for display is the 
current distribution of one f s trucks (including the 
identification of those enr^ute) , and the identity of 
tfie other players. Customed availability for appropriate 
route categories is also displayed when the player 
indicates the route to which trucks will be assigned. 
After the customer pool has been displayed, the player 
has the option of how many trucks to send, from zero : 
to the maximum available. 

This game is not x a team exercise as the term has 
been, used in this document since it represents competi- 
tive* behavior rather than cooperative behavior. However „ ; 
' it would be relatively easy to modify the game to show 
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te£m behavior simply by delegating the rental responsi- 
bility for each company to a group of regional office 
managers* Since there four cities^ in the game, each * 
team would be composed orlour players. Together, they 
would have to develop a strategy for moving the trucks 
in the most optimal way. t 

The team demonstration did Wt employ the regional 
office manager stp£3fegy because 6$ the added complication 
it would impose. ^At least eigh,t players would Ve needed 
with increments of four thereafter. As it is, apy number 
of eight or less, would be appropriate (even including ^ 
only one -player but *at the loss of the competition 
element). Also, most observers will be readily capable' 
of making the mental extrapolation frok the current 
version to that of manager teams, even without actually 
playinf in the team version." Therefore the^ present 
version appeared to* be satisfactory and the* development 
of the regional manager team version seemed unwarrantetf 
due to the dmpracticality °of assigning players. * 

The truck rental £ame appears to demonstrate the 
interaction among participants reasonably well. Time 
needed for the demonstration of the basic concepts can 
vary .from -a minimum of little more than five minutes to 
aft. hour or more, depending on .the interest of the players. 
Orientation to the game consists of a few short para- , 
graphs of instructions^ and even these* can be skipped 
.if the demonstrator prefers to 'orient the players verbally 
Nothing is told to the players about appropriate rental 
strategies. These are left to be worked out individually. 

This truck rental game seems* to fill most of the 
requirements for a short, interest-grabbing, demonstration 
of interaction among players on a common lessoh scenario; . 
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This effort did, indeed show that ^technical authoring 
problems. in the PLANIT system could be overcome in order 
to. implement an authoring- strategy for the training of- 
teams. It also showed that such strategies must be 
simplified through ameliorating authoring conveniences 
in PLANIT i^this kind of authoring is to .become practi- 
cal for the ^ordinary ability-levels of authors. . 

.'The attached Guidelines ought to provide much needed 
V information to authors who might attempt to develop" team ^ 
lessons. .There is little" doubt that the authoring of 
team scenarios is more difficult than comparable individ* 
ualized scenarios, particularly when intricate synchroni- 
zation of the respective lessons is required. " Required 
lesson communication across, team members further compli- 
cates the authoring, and Jhese cpmplicating factors will 
be the norm rather than the exception when serious team 
authoring' is contemplated (for .reasons which were discussed 
earlier in the definition. of team training). However, • 
added complication does not necessarily imply lengthy 
sections of lesson code. 'This can be ameliorated by new 
authoring directives in PLANIT which perform the required 
• operations in concise statements. Also, the added com- 
plexity need not impose too great an extra burden on 
authors if the Guidelines for® team authoring communicate 
as they should and provide relevant examples.- That, of 
course, is the intent of the attached Guidelines. 

' Finally, team authoring capabilities in PLANIT are 
still new. Attempting to find related experience in other 

" comparable software systems has been unproductive. There-, 
fore, it is reasonable to ; expect that new modifications 
will' be recommended from time to time, with the result'that 
any documentation attempt will become obsolete very quickly. 
It appears that the' rapid; obsolescence .of manuals cannot 
be avoided at present but, with that problem in mind, the 
attached Guidelines were written to refledt not % only the . 
current status of "PLANIT. but also the status as it is 
expected to exist after the next major. modification. This 

, approach assumes that there -will be opportunity to make 
those changes and that the' changes will be made exactly 
according to the. design. -However, the benefits of having. 

--available for a longer-period- of- time- a valid document • 
seem to outweigh the risk r that the assumptions might 
suggest. , < ' , . 

. * O ■ ~~ t * « 
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APPENDIX A' NEW^AM AUTHORING DIRECTIVES RECOMMENDED FOR PLANIT 



Regional 
Educational 
Laboratory 



June 22, 1977 



. f 

710 S.W. Second Avenue < Portland, Oregon 97204 • Telephone (503) 248-6800 
v 



Mr. Jim Baker 

U. S. Army Research Institute - 

PERI -OR . v ' " 

5001 Eisenhower Avenue^ * , • 1 

Alexandria, Virginia 1*2333 " 

Dear Jito: \ 

I am sehding the^ June,- 1977 monthly report early 
in order to put some ideas before yqu.- Some" pertain 
to work that I shall be proceeding ^with as soon as 
we reach accord, and some w:ill-be of a more long 
range nature. * 

I have come up with a package t>f new additi6n\ 
to PLANIT, all of which are directly or indirectly- 
connected with the extensions which we planned for 
the team training capabilities. You recall that I 
was to submit a, plan so you could react before 'the 
additions were actually put into PJLANIT. 

The plan I would like to submit goes beyond that 
which can be accomplished , in the remainder of the 
summer under the SDD extension, but I think it would 
be well to consider the plan in its entirety ^nyway 
and carve out that which could be done now. I am 
satisfied that these new conventions would ^supply 
everything that SDD needed but lacked in theij^ef f ort , 
and then some. There are some rainif ications for two 
of these changes which I will go into. 

Essentially, the •plan. calls for adding six new 
features to PLANIT and changing two friore that are ^ 
already there. I will take them in order, with a 
brief explanation of what is intended. This may also 
call for some more discussion over the telephone. 

1. Th£ SYNC feature. Its lesson forms would be; 



\ 



\ 



SYNC(Tl,T2,*-STn;N)" 
X=SYNC(T1,T2/- • * ,Tn; N) 



iir 



AN EQUAL OPP0RT0NITY EMPLOYER 
- 25 - 
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SYNC does Jthe following: — > . < 

• Allows lessons to have punctuated synchronization 
points ,at which all" players will wait until all 
ha^e caught up. 1 ' 

• Allows^ lessons to* have numbered synchronization 

points to guarantee that aU ajgrs are^^ ; ^ 

synchronized at the appropriate place In their 
respective- lessons. 

m Allows some players to leave the team setting 
f z*nd work on their own while the remainder of 
the team continues to work as . a team without 
him (them) . , 

• "'Allows players who have left the team to work 

on their bwri to rejoin the team, find the place 
■ where the ,teara. is currently working, and become 
a team member again. 

* In the SYNC format, the Tl,T2,--',Tn names an 
arbitrary number of team members by their terminal 
numbers. 'These numbers can be acquired through the 
COMMON matrix as the current team lessons do. The "N" 
following ^he semi-colon can take on integer values fronj 
zero upward. A zero value means that this player is 
leaving the team for awhile. Larger values represent 
synchronization numbers. They can coincide with topic 
numbers, frame numbers, or whatever. They indicate - 
how far the team has progressed. The ;N can be omitted 
from the statement and '*N M will default to "1", indicating 
a simple synchronization point that is not define&<»^ 
a sequence number. A return value can be assigned to 
a CALC variable ( M X M in the-example) T This shows the 
highest synchronization sequence number reached by the' 
teairf, and can be uied by a play.er who wishes to auto- 
matically find the right lesson location, where to rejoin 
the team. 

If the team is not yet completely assembled when 
a lesson -executes a SYtfC statement, the computer will 
ask the user whether he wishes to. wait. This will 
provide opportunity to automatically assemble the team, 
a task that required several frames in the SDD lessons. 

This SYNC command can be implemented under the 
current contract . m ' 
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2. The SPECIAL- command* 'This cbramind already exists 
in CAL'C and % is in fcse in Li item's ernianaements example. 
I propose that we reduce the dumber^ f arguments to 
eight 1 (instead of the present ten), £pd provide several 
new capabilities in ^addition to those that are already - 
thetre f including: '■ - 



> 



The ability to make the lesson wait for an . « 
action that may not complete for awhile. During 
the wait, that user will not be consuming computer 
"time. % This ccmld be a wadJt for a light-pen input 
for example. , * r~ \ 

* * I 

' The ability to put-, the user into t an OK/ CANCEL 
mode where he will 4 not proceed until he receives 
thef OK (or CANCEL) from the dperator. m A good 
case for this would jbe attending* to write' on 
a plotter where the operator must first make- < 
the plotter available. t . 

Some alternative actions jvhich^ MIOP could-cause' 

the lesson to take, such as reporting an -error, <x • % 

lagging off the^ser, etc. i 

Put all buffered messages out to the user before 
'the SPECIAL call makes Its request to MIOP. 
This would simplify some timing" problems. 



The current capabilities would be 'unchanged (except for 
the reduction in the number of arguments by two — there* 
are probably too many now anyway). Hefa&J.t conditioris 
would revert to the present- kind 'of operation. 

This change would have s6me ramifications for Litton. 
They are ye^y probably the only ones "who have used the 
SPECIAL call/*scJ\f ar. When they mounted tlpLs version, 
they would hWe \oimake a minor change to their^ MIOP 
(less • than an\^ugftL^and edit out the last two arguments 
in the SPECIAL oftlls in their enhancements lessons. 
'These ,can be done with it*he PLANIT M command. 

I believe this ciiange is needed and if it is postponed 
it will oSly cause more problems as more r uses of that/ 
call are made. The 'change can be* made under thes^paresent 
contract. % 

. " The remaining items prob^tfly cannot be done under the 
current contract but they together constitute a package 
so I will .describe th^m. 
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3» There *are three "command Variations here: 

SET HEPLY(n)=" composite expression" 
. FEZQH REPLY * 
PUT REPLY ; * 

Ther.e is already a SET REPLY.(n) fthich Captures 
the ipost recent, terminal input. This ttould not change. * 
It would only add another.. way of pitting information 
into the REPLY buffer. The "composite express ion" \ 
format would be exactly the same as following a PRINT 
statement, where words^and CALC values can be pieced 
jtogether into a singl'e^line. In this case, instead of 
being printed on the terminal, it would be loaded into 
the REPLY buffer^ From there, it can be printed, used 
in *a Group 3 match, or whatever* 

Couple* the abcive with the FETCH and PUT and it makes 
a powerful ^team option. The FETCH and PUT would do for 
the entire^ array of REPLY buffers what it now does for 
the Common ""matrix, it would allow lessons to exchange 
copies of these buffers. It would enable ofife Xles,sqri 
to construct^ line, send it to. another lesson' and 
that^less'on use it in any fashion, such as to hold .and 
print a message at the appropriate time* to submit a 
reply at one terminal*- and matph on it in a different 
lesson, etc* The possibilities -Here stretch the imagina- 
tion. t , 

' This is one case ifoak wou\d. have to vJait. It- would 
not interfere with present .lessons but/be new options for 
authors. Therefore, it would-be better to save it for 
*the next contract. 4 . . , 

4 * 

4. This one is a suggested change for. the use of thev - 
DIAL command in CALC." The form would be: 

. DIAL n* "composite expression" 

The "composite expression" would be the same as for the 
SET 1REPLY option^ kbove. li would permit the dialing 
of much more flexible messages across terminals, including 
values of" CALC items. * , 

The present CALC. form of the DIAL command has some m 
problems when the Author • tries to put /characters into 
the DIAL message, that CALC does not accept. The above 
format would bring the DIAL Syntax back ifcto conformity 
with the CALC language syntax, as it' should be. 



The SDD lessons are presently the only cfne% that 

have used' the DIAL command in CALC. These 'DIAL 

statements would have to be modified by putting 

quote or prime (" or T ) delimiters arouiu^ the present 

messages. When properly delimited, any character, can 

appear in the message. It would not be a daffictilt * 

change- tp mafce. .• ' . 

. ~ ^ $ 

* I recommend that we plan to make this . change but 
will hot have time to do so ufitil the next contract. 
The .major work will, be the ".composite^ expression 11 
which both options . : p£h- share so the REPLY change* and 
the DIAI/ charige showd be done together! 



5; the la£t one is an ESCAPE option for authors who 
program themselves 'ift-to trouble. Since* team lessons 
are' somewfiat more difficult," it is probably even more 
.needed for team authors*.. The command form is: 4 * ' 

ESCAPE(n) - + ' 

SET ESCAPE(n) ' # > - tf 

It would be used exactly like the WAIT function 
in J^A^IT, where the value could be SEf for the 
duration of the 'lesson, or only for one frame. The 

'ESCAPE option says to log off ♦ any student who uses f 
more than "n" seconds lot CPU time between terminal 

'inputs, "Its purpose would be to automatically break 
loops -that' the author may have" inadvertantly put there. 

ie default valine "for ESCAPE should probably 0 be 
about So, seconds but the author could raise that" Tf 
the leisbn* was' goipg to do a JLot of computing in a e 
certain section, as for example ,\might be done in a 
■simirf atiori program. . * . • 

If this^option had be?n available for SDD w^ile ^ 
they were working on their Wessons, it probably would 
have saved them * thousand dollars or more. - It/is? not 
unusual' to" get looping started, in the lesteoa, and it 
takes "an operator on;the current system td^ stop it. 
The ordinary author or student would not know how. 
The operator must QUIT that user. The ESCAPE option 
would dp the same thing after the prescribed amount 
of CPU time had elapsed. It would <be automatic so that 
the cost of it- would be negligible and V message would 
come t^lthe terminal warning of the probable cauSe.v? ^ 

' There may be time to jLncXude this* under the 
"CHrrerit contract but I wourti. wapt to vaW and see..,; It 
wtflild haye no negative impact on current lessons. 
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.These above options constitute* .the plan. ^ Taken 
together, they provide-an excellent package for . 
enhancing team authoring, particularly for- thoser: 
features, f ouncL lacking_in the SPD exp erience. I 'am 
certain triey Wouid have found most of them quite useiul. 

One 'additional' feature of this plan which has 
become very ^import ant. to the PLAN IT system is that 
there would"^ at most two or three additional data 
words rea'uired-'for 'all the new Options combined. * This 
would amount to an insignif iojaht increase in PLANIT- s 
Common data space. There- would-be' quite ra' lot -of ^ new 
code involved but this can be arranged so that it' can 
go either in core^or in an overlay, at the .option of ,, 
the installer. Thus, there would be ^virtually no size 
increase in PLANIT (i;f . overlaid) which would be a Vital 
consideration for installations such as the PDP'ill.. . 

, Depending on the outcome of the consideration 
or 'this plan, certain other factors enter into the ^ - 
decision making: 

1. - The .obvious question 'is whether these recommendations 

are satisfactory, oV whether you might want to - 
change the '-qptions , the order of installation, ej,c. 

2. 'When writing my^report on ef feet ive f team lesson 

authoring,, should I include -all of these options 
or limit the text to 'that which PLANIT currently 
executes. 



3. Should' the Teaiir^Benchmark lfesson include these. new 
optionsV- * " ♦ « J 

4. ' On the assumption ^th at the addition of new^ptions 
/ would mean a new PLANIT release^ (version 3. 2.) , is 

it-time to change the "update" document' (a copy is s 
attached)?*. It is already bfhind .(version 2.8.).. . 
, -Finding time .would be the 1 next question^. However, f 
: if you are thinking o"f a more involved effort at a 
. later time of 5 producaJng new user manuals, theaf that" . 
< • 'might influence \^.t we do in the interim. 

, «^/» 

I have had a- lease*d telephone line on order for . 
, about six weeks now and it should be in before too long: . 
Having lost my unlimited WATS line, m that was 'the least 
expensive option. As soon as it. is in, I want -to begin 
work on the changes. Would like to consider your* Jeedbhck 
on thiS^plan by 'mid- July, or before if .possible. I hope* 
thaf is not pushing you. : . ' 

■* 

Sincerely, > ^ 

K +' j ' Charles H. Frye 
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ABSTRACT 



/ 

This document contains guidelines to help a, PLANIT 
author write effective team training scenarios* In 
'order to benefit/from all of the described, features 
of the language, the author mu^t have access „to an 
installation of PLANET Versibn 3,2 or above. However, 
those features which are not available in version 3.1 
are marked so that they can be avoided in the interim 
until access iK^^versioti 3.2 has been provided. 

The document Stresses -the initialization, manipu- 
lation, and readout of data in the Common Data Space, 
a facility that will normally be needed in team 
training applications. It also discusses how to get 
the team started together, keep them synchronized, 
gqt them going again in the event of an interrupted 
session, and provide necessary cross communication. 

It is expected that the reader has already 
acquired some proficiency in the authoring of conven- - 
tional PLANIT lessons. ; 



'•s\ \ 
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AUTHORING GUIDELINES FOR 
'PLANIT TEAM TRAINING SCENARIOS 




Cowputer-administered team training is *a relatively 
new 'form of computer-assisted instruction (CAI), and 
authoring skills required to produce the training 
scenarios seem somewhat more complex. It is still too 
early to determine whether this added complexity stems • 
from the nature 'of the task, its novelty or awkwardness 
|pf the authoring language (or a combination of the th^e) 
but the present CAI authSbr can be expected to need 
extra help when attempting to develop such scenarios. 

This document attemptL to provide such help for 
PLANIT authors. PLANr^(Programming LANguage for/ 
Interactive Teaching) is a CAI system for autfrqring v 
arEPd administering training scenarios. lucent efforts 
have introduced special capabilities into PLANIT which 
were found to be necessary adjuncts for the authoring 
"and administering of team scenarios. -Through initial 
experimentation, additional team capabilities have been 
defined for the language which, at the time- of this 
writing,, have not yet been implemented in PLANIT. 
However, >^his« document will include tljese ne^£eatiires 
jLn its discussion anyway, anticipating the time when 
they will become available. 

, Thus, this document will present authoring guide- 
lines, some of which cannot yet be used until the ijext 
PLANIT version is released, version. 3.2. The features 
which will riot be ready until version- 3.2 will be marked 
in the text with, a double asterisk (**). The absence 
of this mark will mean that the 'authoring feature is now 
available in version 3.1. 

It .will be apparent to the practitioner that the 
special team features will make up only a sfoall part of 
the scenario ,• that the bulk of the scenario will be 
6ompos^d of conventional CAI authoring directives.. 
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Also, in some cases, the special team directives will be 
a variation of convent ioWl/ directives. The. printout x?f 
a team lesson .wifly look much lik$ the printout of a • 
conventional legspn, It will be the strategy , around which 
the lesson is;, structured that ^will deviate from the conven 
tional • . 

' * The strategy of team lessons will normally demand 
interaction among participants and. with a common source, 
of information* The concepts of team training are . 
discussed in a separate document , a final report to the 
United States Army Research Institute for the pi^oject, 
"Extension of Computer-Assisted Team Training Through • 
a Coordinated Lesson Scenario 11 dated September, 1977. 
That document discusses the rationale which engendered 
the design of the 'special team authoring directives in 
PLANIT. Therefore, the need for performing, these 
operations will not be described or defended in this 
document bnz rather it will be assumed that the reader 
has aix^dy encountered these^ needs either through 
reading or practical experience, and is now looking for 
assistance on how to implement them in the PLANIT lan- 
guage. m ^ 

In addition to tJfe assumption. that the- reader 
is already aware of the special team capabilities .that^ 
will be needed, it will also be assumed that the^ reader* 
is an accomplished author of conventional PLANIT lesions. 
Authoring manuals already exist for PLANIT with respect 
to conventional lessons and, as was already mentioned, 
these conventions will fotm the s bulk of the team lessons 
as well* 

t Finalljr, there will be instances where alternate 
methods are % discussed whic^i impletaent identical 
^(or very similar) operations. In all cases, the first 
of the t alternates^will be* the generally preferred method. 
Hotffever, > the .alternates will be discussed either because^ 
some necessary component of the main metho d may npt yet 
be implemented, or because the alternate method may > 
contain, some vaxriation^. which may make it preferred in 
some unusual cases-; ' although it is" a bit soon to attempt 
to sort out the usual from the unusual in. such a new 
application. • • ^ 

Before discussing the various authoring guidelines, 
a ^summary of , the present and planned t6am training 
authoring . for PLANIT will bfe presented. 



PLANIT AUTHORING DIRECTIVES FOR TEAM TRAINING 



• The team training authoring directives wili be 
grouped according to those which are available for use 
in PLANIT, version 3.1 and those which will become 
available with version 3.2. Note that this distinction 
will be made in future sections of* this document by 
the addition of a double asterisk (**) superscript % 
appended to the directive in question. If the reader 
happens to have a PLANIT version 3.2 or higher, 'the 
distinction could easily be removed - from the document ■ 
•«with 9/ little correction fluid. 



Team ^u^ioring Directives, Version 3.1 ' 

These authoring 'directives consist of a Common 
Matrix capability with the FETCH and PUT commands, , 
,a TERMINALS variable for identification of the user, 
2nd an extended DIAL feature so that it can be used 
" wi J& in the lesson ana during execution :via the CALC 
mode of PLANIT. 

* s The Common Matrix is a feature for placing a , 
c 9Py^C \ any«9use r-def ined matrix into position so 
.that it ygh. aVallable* ,for inspection and use by all 
members of the^ team., EacJ&Nrorks on his or her own 
'copy of that matrix^— and Wfthe matrix is to be 
updated, -it occurs by writing the locally-updated 
versajsrfisack over the Common" copy . The directives 
are used via CALC and-, include: 

o * 
m * 

. . 'PUT X . * ' ■ 

- ' > 0 , 

* FETCH X . 

where * M XIL is any locally-defined matrix.. In the 
case of the FETCH command, the dimensions of the 
local "X" matrix must exactly match the dimensions 
of the*,matrix which was most recently PUT into tlte 
Common space. Any dimensions ard acceptable for the 
originating matrix, so long as ^the Common space can 
accomodate the total matrix sijace requirement. , - 



In general, the FETCH and PUT directives provide 
opportunity for the interaction of several team members 
with a common data basQ. This data will always be 
numerical although the numbers might be interpreted to 
index some alphanumeric sequence. 

The Common Matrix will be ^common" to. those team 
members who have begun their instructional sequence 
in a common PLANIT lesson module wherein the Common 
Matrix if first defined, i % e# is PUT into the Common 
space* A sufficient definition of a Common Matrix can 
be accomplished simply by declaring any matrix of ap- 
propriate dimensions .(whatever the lesson will need), 
and then PUl\ that matrix name irv a CALC command. This 
will preset the Common Matrix space with zeros and 
cause the identification of that Common Space to 
follow each of the team members into any sequence of 
lessons they might encounter. Any subsequent FETCH 
command will reference that Common Matri?. Strategies 
for achieving desired results will be discussed in the 
guidelines to follow. Note that it would be equally 
appropriate to preset any desired values in the matrix 
prior to the initial PUT operation to preset non-zero 
values in the Common .Matrix. 

DIAL t 1 Message. r • - 

<* 

The DIAL command which has 'long been available in" 
the Command mode of PLANIT is also available as a 
CALC directive. However, when used in CALC, there 
are certain additional features and restrictions which 
are not true in the Command mode version. 

First, the "t" following thq word, DIAL, can be . 

a literal terminal number (as in the Command mode), 

or can alternately be a CALC variably name whose 

current value, is equivalent to the desired terminal 

number. . , 

« 

- o As is true of most CALC 9 directives , the DIAL 
command can be used within the lesson scenario, 
following the "C;" prefix, or can*be used in real time 
by the trainee who uses the appropriate prefix control 
character to gain access to CALC. Thus, both the. 
lesson and the trainee^ can send messages to other 
team members (or other .PLANIT users in,. general) using 
the DIAL directive. Note that PLANIT must be installed 
in such^a manner that it controls the -time-sharing of 
its terminals for this DIAL command to funcrtiou. Also, 
the installation parameter,, "WRITETHRU" will' require . * 
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consideration in order to make the DIAL command function 
in the manner desired at the local site. These consider- 
ations are -discussed, in the installation information. 

Two name particles have special meaning when u§ed 
immediately after the DIAL command, in place of the "t" 
in the example: OP and ALL. OP will refer to the 
PLAN IT operator and ALL will designate all current 
PLANIT users. The latter (ALL) will only be allowed if 
the user is the PLANIT operator. 

f Finally, the enclosing prime ( f ). delimiters are 

suggested rather than required. Use of the DIAL com- 
mand in CALC causes certain of the characters to 
receive special consideration which is not true of the 
Command mode equivalent. ^However, if the message is ; 
enclosed in primes, any character (c 'her than a prime) 
can appear in the message without causing undesirabljf . 
execution. Also, the 3;2 version of PLANIT is expected 
to require the use of the delimiters. Therefore their' 
use is also recommended prior to 3.2/ * > 

TERMINAL ' 

The TERMINAL particle name is a system-defined 
name for the current terminal. This same number will' 
appear at login time and is the one to be used by 
another PLANIT user who desires to DIAL a message to 
this terminal. It was' added as a partvof the team v. 
training package, since this is the f irst^pplication 
that" specifically requires the identity <ff one terminal 
±o be known at another. The identities are normally 
exchanged between participating lessons through the 
Common^Matrix, where designated elements *in the Common 
Matrfrx are given the value of TERMINAL when the nejv 
member signs on. TERMINAL' is used in CALC in exactly 
the same manner a$ .such 7 variables "as FRAME, TIME and 
RESPONSE. o • \ 



Team Authoring 'Directives, Version 3. 2 (New *£nd Revised) 

The following features are beiri£- 'kdded to PLANIT 
to enhance the Common Data Basp; Simplify synchroni- 
zation of team members,- make the DIAL command corres- 
pond to standard CALC syirtax, and provide failsafe 
escape'routes for lessons 'which may be caught . in- an 
infinite loop. - : v • 
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PUT REPLY 
FETCH REPLY 



••Cs»e.- 



The operation of these two command forms Is completely- 
analagous to the PUT X and FETCH X forms for the Common 

Matrix. The difference is in the fact that the REPLY 
particle names a series of buffers each of which may 
contain any arbitrary single line of characters. • Thus, ' 
this new feature adds the, alphanumeric dimension to the ^ 
Common Da t.a. capability. JtTote that this does not replace 
the Common Matrix features, but rather JLt enhances' them 

. by providing a Common capability for non-numerical data. 
.It is assumed that the reuder is already familiar with 
other uses of the REPLY buffers, or can become so by 
reading the PLANIT 'authoring manuals i 

One additional new use of "the REPLY buffers completes 
the plan for Common Alphanumeric Data: 



SET REPLY (n)= ' composite ejfpression 1 



where "rij> is any literal buffer number (or expression 
which evaluates to a literal buffer number) that is^ within 
the range of admissible buffers, a parameter that is 
determined at Installation time. The 'composite expression' 
~£s~ any mix- -of- delimited character strings and CALC values, . 
separated by senii-colons. ( ;•) . The ^composite expression', 
is- identical to ""the forms* 1 permitted in the composition , 
of thill PR I NT statement in CALC where alphanumeric strings ' 
can be mixed with CALC values to compose a single message.. 

Initialization of the Common REPLY buffers is the 
same as for the Common Matrix, where_the first PUT 
command must be encountered by all team members, in the 
same initial PLANIT lesson, after which the identification 
of the Common REPLY buffers' will follow the team member 
regardless of £he -subsequent routing through 'lesson modules. 

' , ' . . ' ... 

. ■ The DIAL 'directive I-n CALC is being changed to the 

-form: 



DIAL t 'composite* expression' 



where "t"\is the terminal designator as before, ^he 
change is in the 'composite expression' portion which , 
becomes identical to" that* shown above for the SET REPLY 
•directive. - Note that DIAL messages which are enclosed 
within delimiters in the^-format cited earlier will work 
.without change in this one, motivating .the recommendation 
that all' uses of DIAL in the lesson; follow that format 
regardless of the version number. 



\ 
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A new synchronization feature is used to coordinate \ 
the activities of- all of the teamxmembers . The SYNC 
command form is*: X> ^\ 

X=SYNC(T1,T2, • ■ • ,Tn;N) 

where "X" is any simple CALC variable' namp, Tl,T2,^*,Tn 
are terminal numbers denoting team members (or expressions 
which evaluate to said terminal numbers), ^and "N" ^ 
is a lesson-assigned number that is positive and increasing 

• inmagnitude each time it is used in the lesson. 

The function of this directive is to synchronize the 
execution of all team members of a tegm. lesson at . a 
given point designated by an N value. Each team member 
will be held at that point until all have arrived and' 
then will progress together. The value returned to X . 
will be the highest N value posted to that time by any 
team member. , Knowing this value allows the lesson logic 
to place out-of-sync team members back into step with 
the other members*. 

The*N value can be a positive integer or have up to 

• two decimal placfes. PLANIT lesson frame numbers would 
be a logical value to use for. N. Ah N value of zero (0)' 
has a special meaning irr— that it is used to temporarily 
drop the synchronizing Relationship with the other team 
members .until such time as another SYNC call is made with 
a non-zero N value.* While the sync' relationship is 
suspended, the remaining team* members will proceed in 
their normal synchronizing relationship without regard 

to the one who has dropped out. The suspended member 
can be re-positioned in the lesson sequence by using 
the value returned from a 5YNC call to determine the 
present team location. 

Variations of the SYNC call include: 

* » • v * * * * 

X=SYNC(Tl,T2,---,Tn) , % 
SYNC(T1,T2, ■ • • jTn; N) ' 1 
SYNC(Tl,T2,- : -,Tn) 

where omission of the X value means that no return value x 
•is desired, and omission of the N value mean$>that N 
wiU. take the value of the next' whole number larger thaii> 
6 the^ current X va5?ue. * * 

In addition to r the above, the SYNC feature ^ill 

• also, function .ti^id^he initialization of the team 



exercise, to % initially Assemble the team members, and 
to inform other team members when one leaves the team 
exercise ♦ - 

The final new addition to the team repertoire is 
not directly related to team training at all, but 
rather is occasioned by the kinds of problem? -oifcten 
encountered in authoring t^am* lessons. This feature 
is designed to break infinite lesson loops. The 
command format is : 

ESCAPE (n) ♦ < *~ 

where "n" represents "j^he number of processing seconds/ 
to allow between terminal inputs. In the absense* of 
an explicit command,, a default , condition of 60 ^seconds 
would "be allowed. If that processing time is exceeded, 
the user would be so infprmed, Earned of a possible 
le^spijl problem, and logged out. 

/ • ' 

The need for the fiSCAPE -command stems from an 

often-used strategy in team lessons, that of monitoring 

some eveht within a lesson loop. * Using this sjtjcategy, 

it ,is very easy to find oneself in an infinite loop 

fro^n which manual escape is ^difficult, requiring the 

intervention of the - PLANIT>6perator. Meanwhile, 

processing charges accumulate "and service Regenerates 

for the remaining inkers. The ESCAPE f eature^provides. 

an easier mean§ for breaking .such loops, in fact they 

will be broken automatically" unless the lesson author 

-should specify such a' la^ge ESCAPE value that would 

render the -feature inef fe frl r fry fe, which might be important 

if uriusual&y long processing was to be expected at that 

point in time". ; 

^ , i 

. < I 

Summary ' * # k * *V* 

1 Special team Authoring features in PLAHJT, both 
extant and planned, have^been" presented only to the 
extent of describing the^Bommand forms and the basic 
purposes for each cbmmand. The next ^section will 
attempt to describe hw these commands are used to 
implement teai\ training strategies within the PLANIT 
system. * ' v • * , ■ * 



TEAM LESSON STRATEGIES 



The PLANI't Author who is accustomed to writing 
lesson scenarios for individual execution will find 
-some reorientation of thinking necessary when dealing 
wirth several (two or more) participating team, members 
who are interacting with the lesson and each other. 
Certain 'PLMIT features which work very well and are", 
easy to us,e in the individual setting become much, more 
complex for teams* The concept of re-entry into the ' 
lesson -is one such example such that the punctuated 
(dotted) frame type re-entry provision may not produce 
the desired results, • i.e. might not get the team^ack 
together and into the lesson again. It would certainly 
not be a sufficient provision by itself. 

Thus, this discussion of team lesson strategics ^ 
will be structured around several components which/seem 
to be' present, to some degree, in all team autttoriftg ' ^ 
projects. ' - # * 



- Initialization " ^ 

* 

Mbst lessons s^em to require -some initialization 
of data, mostly CALC data. Once initialized, the data 
follow the trainee in the form of a "student record" 
such that the training session can be interrupted for 
ahy length of 'time and yet? allow the trainee to resume 
wherever the author provides. There is rarely a ri^ed 
to change the conditions of the initialization when tlje 
trainee resumes. However, in the* case o£ team training, 
re-entry into ,the scenario' following an interruption \^ 
<ja«sbe a problem since some of the initialized-^data may 
no longer be valid. Specifically, assigned terminal * 
numbers wiJLl often be* a necessary part of the initial- 
ization process for team lessons, and these could easily 
change after an interruption. 4 • 

Also, from minimal- experience with team lessons, it 
would seam that team .sessions would normally start from 
the beginning of the scenario whereks individual lessons 
normally resume at some point near the' interruption.* 
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. And, after current , teams complete their exercise and 
a new ^eam is iab'out to take their place, -^there may be some 
residual, unwanted data left in the Common Data Space ^ 
(Common Matrix and Common REPLY Buf f ers) ' that needs to be 
disposed of first. In this case, although new trainees 
sign on with clean student records, there will often be 
some residual team data yet remaining^ r 
* * " * 

In considering methods for use to initialize the 
data spaces appropriately, one must avoid initializing 
too .much or too often. Fox* example, suppose a .three- 
member team is attempting to sign on to a team lesson 
scenario which incorrectly initializes all data Uncondi- 
tionally for each new trainee'who starts. In this case, 
each new addition to the team, would erase from the Common 
Data Space all record of other members who had signed on, 
leavirig a team composed of one member, the last one who *» 
signed on. Thus, initialization must be controlled to 
occur only when it is needed and not when it will 
'adversely affect lesson execution. . 



AUthor-Controlled Initialization . The- author can assume 
responsibility for initializing the 'Commoa Data Space 
prior t 4 o*each new team Who signs onto the system. This> 
ean be dorfe- by signing on in 'the Author Mode, switching 
.directly to QALC, 'declaring an appropriately dimensioned 
matrix, blanking a^L of the REPLY buffers, and then use ' 
the PUT command to update each\in the Common Data Space. 
(Whether ^either or both must be initialized will t?e 
determined by their use" in the scenario) . 
» */ 

"'This method wilTWccomplish the necessary init- 
ialization to the point tljat simple ,lessoh logic can , 
complete. * However, this mathod ; obviously requires the , 
presence of the author (or a trained monitor) ' at all 
sessions; nega l tirife some "of the important benefits of 
us^g "the computer iri the first place. 

Trainee-Controlled, Initialization . This uses the first 
question in the scenario to ask if this one is the first , 
member of the present teaifiyto sign. on. If so, the lesson 
logic proceeds to initialize the Common Data Space via 
CALC lesson ^commands. Otherwise, the initialization step 
is skipped. ' 
* «. * — » 

This method works quite well if the team members 
are geographically together ajid have voice communication. 
Otherwise, a well-meaning team member might anjjwe> , 
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incorrectly ^jid erase needed data. This would require 
• cdreful queueing in advance ♦ *' + 

Lesson-Controlled Initialization, . This would depend on 
the capability of making the lesson detect ithe first 
team member to sign on to perform the needed initiali- 
zation. There are' probably, several ways to do this . 
but two will be discussed. ^ * 

The most'. 'direct method is .with the SYNC command 
where a PLANIT Decision frame would corftain something 
like the following statements: 

-C:SET MATRIX (X, 100) 

• CiTETCH X - 

, IF SYNC(X(l),X(2),X(3);t5^Q 0 ; , * " ^ 

Proceed to initialize. ^ 

'• END y - — — — < - - - - - ■ 

Proceed with the lesson. * 

<* 

' Irf the above example, an assunfed three team members 
whose identity is assumed to be in the first three entries 
X of the- Common Matrix is tested in the SYNC** command with 
>a zero synchronization number for the. purpose of retrieving 

♦ the highest presently posted" synchronization number. That, 
number will be zero until the firs* team member posts , 

a non-zero value, which presumably would' happen very soon., 

* into the lesson. Thus, only tlie first team member to 
sign on would find a zero value, and that would cause 
the initialization to occur. Note that a fcero* (0) was 
given for the' synchronization number (after the semi-colon) 
so that this occurance would not hold the user here until 
the others caught up. In this case, execution is intended 
to proceed. 

■ ' * ' '„ 

Another method would use coded values t in the Common • 

' Matrix 'to indicate the present status.* Suppose X(4) 

■ was used to hold the value 0, 1 or 2 with the. following 

meanings: 

"0 = Initial state, no team members yet signed on. 

1 =■ At least one.' team member has signed on and waiting 
jtor the others. * - 

2 = %e- team is assembled and the lesson is in progress. 

; ' i • * * 

With tha£ scheme, the following Decision frame statements 

would be appropriate: 
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- CrSET. MATRIX(X,100) * 

C:TETCH X • * 

IP X.(4) NQ 1 4 " 

C:X»0*X 

G:X(4)«1 
^Proceed to initialize* 

C:PUT X • - 

END * \ 

Proceed with the lesson, changing X(4) in the Common* Matrix 
to the value> .2. • * % * 

This will accomplish about the same as the SYNC** 
. form (above) except that there is a potential for con- / * 
fusion if the team members should for some reason sign 
off while the value of X(4)> % was 1.; The lesson woulld f > 
have to be written in such a wa^ that no additional 
initialization would be needed when the next --team tried|^ 
to sign on. '7 

One final consideration' is the existence of the 
-Common Matrix a^^herijegiiiniiig. , It^wottW seem that all — 
% cases will usp Ihe Common Matrix to communicate the' 
identifying* numbers of the participating team members 1 
terminals to the. pjther participants.. That being thfe 
ease^one 3>f 'tl\e fir.st commands will be a FETCH of., that 
Common* Matrix. m On the very first attempt 'to execute, w , « 
that.iesfe$n;\$or #,f ter ,$Jie' lesson is brought in from cardSsO , 
• the Cpibnofc Jl&trlx will not' 1 yet existf -paving not yet been 
I>&T ift'jpfeke, ;°^:is can tre avi>i<|ed §y one-time effort 
oii^ the part p^v^e^^ithor^tp. deJelara* an" appropriate~size 
matrix, intetfadtivel^^^^^ onto the first 
of the team lesjsron 'se^^3^..an^<tI\em^PU , ^ 'the. matrix into 
the Common Matrix - jspace^ * ^Reysr, ^eginning^with PLANIT 
yersipn 3.2, this problem! '^lll* ptb^longei^^^lSsi: 4 since a 
missing Common Matrix- will be ^ga#ded th.e same as if r ^ 
all its entries were zeros. 4 / ^ — " - ** 



Re-Ini t ializat ion ""V 



By the t%rm, re-initialisation, is^ meant tliS process 
whereby* all pe^tineht data /Sxe returned £p , Appropriate - 
starting values when a new teata signs on.* • 

- Several of the conditions for re-lriitializatiori 
were already covered in th % e discussion ofi initialization, 
above. Each^of the described methods .would , also eilcbmpass 
proper initialization for the next Hajn. However u there ' 
are at least two additional consider at iorife that may or 



may -not be of concern during the process of re- 
initialization. - 



Dafca Readout . It will be normal during team execution 
for data to accumulate both in the individual team 
member's student .record and in the Common Data Space 
(Common Matrix and Common REPLY** Buffers). Although 
the,s,tudent records will be left intact following the 
team exercise, .the Common Data Space will be used 
over again by the next team, changing the data which 
were left by the previous team, What - the lesson should 
do with that data depends on the training objectives. 
If the data are no longer needed,' the*space can, simply 
be re-initialized when. th.e new team signs on (as is 
assumed J.n the examples of initialization, above). Or-, 
the data could^ be allowed to "age" from one team to the 
next, that is, only selected entries pertaining to the 
identities of present team members would be re-initialized y 
while the remaining data space would retain the values 
from the previous exercise, accumulating the experience 
of the team Sessions. Another alternative would* be to 
display the Common Data from a team session prior to 
the next exercise. Each of these will require different , 
. re-initialization considerations'. ' , 

' J Case 1 will- be handled effectively by either of • 
the initialization -examples shown above. When 'the 
new team signs on, the data left. over from the previous 
.team is lost (i.ef^set back^to zerp) . 

Cases 2 and 3 will require some kind of coding 
similar to the use of X(4) in $he above example so 
• that r the lessonrean assess- the previous. status before 
overwriting*"^' data space. For exantole, to reset only 
selected, entries as in case 2, the following Decision 
frame statements would work: . m • 

C:SET MATRIX(X,JLO0) . * 

C^ETCH X . 
IF X(4) EQ, 0 . 

New start, initialize everything. *" „ 

' IF X(4> EQ 1 T 
Already initialized and in process of assembling tne.te; 

^IF X(,4) EQ 2 ■ \ ^ f * y 

.Re-initialization. Reset only the appropriate entries. 

END , . ' ' • . • 

<J:X(4)-1 • \ - 

CiPUT X * 

Proceed wifeh the lesson. Change X(4) to 2 after the team 
has beep, assembled and the training begins. 



Case 3 would be a variation of this example. Instead 
of selectively re-initializing for X(4) equal to 2,\ 
appropriate action would be taken to preserve the d?/ta. 
This might take the 'fosm of a display o£ the datW (to^ 
be given* to the author), or a message which informs the 
user that the data from the last exercise has not yet 
been retrieved, and*then end the execution with a" 
C: FINISHED statement* After retrieving the data, the * 
author would initialize the Common Matrix to re^dy it 
for *the- next team. 

Team Interference . While the team is being assembled, 
two members cannot be allowed to x get assigned to the 
same position, and dfter the team has assembled and is 
executing, no pther person can be allowed to sign on 
to that team sequence and interrupt their execution. 

*A simple solution to these potential interference 
problems makes use of the earlier system for designating 
elements within the Common Matrix, to represent . the 
terminal numbers of the participants. Injthe initial- 
Ized condition, .these entries would bg zero. The 
earlier example used three-member teams and the first 
three ^entries to represent them. Continuing that 
example, if the entry^xs still ,pero, that position 
still needs^a team member. 
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A PLANIT Question frame can be used to ask which 
position. in the team the person wishes to occupy. 
Having evaluated the choice, a Decision frame then 
checks the corresponding entry to< determine if it is 
still vacant and, if so, assigns the TERMINAL value 
to it.' If not, the user is so informed And given 
an opportunity to choose a different ^position or is 
signed* of f . However, if each of the entries is / 
already non-zero, the user would not be allowed /to 
start, but rather would be informed that all thd * 
pdsitions are -taken and would be signed off. This 
logic can be seen in the example which appears at 
the end' of this section and incorporates all of those 
things considered so far. * , 

Replay . An additional re-initialization problem is 
encountered if the same student identity is to be 
i^e&sed for a subsequei^b team exercise over the same 
lesson scenario. Thetfe will already exist records" 
for that member which direct PLANIT to the place ' 
in the scenario where the person should resume. 
However, in the case of the team scenarid, there 
will first be fr-need to reassemble the team; * * 



* All of the various options that might be desired 
for this situation are too numerous -to cover here, and 
each will demand some logical variation in the lesson 
scenario to implement it 1 Three cases will be described. 

Case 1 might be where every new session is to start 
from t£e beginning of the series. In that event, the 
first frame of each lesson module should be punctuated 
by' "dotting" the frame type. For the first lesson module 
in the series, whatever frame is first would be dotted." 
In subsequent lesson modules, the first frame •"that is 
dotted would be a special Decision .frame, as follows: 

frAme*i.oo~Td. ) * 

g2. criteria „ 

IF LINK(l) EQ n Bi START j 

LINK(l)=n . . 
* • ^ 

The value "n" can be any number so long .as it is non-zero 
and different in each lesson module. The name START is 
to be replaced by the name chosen for the first lesson 
module in the series. No other frames should be " ^ 
punctuated. » 

Case 2 might, be where the - same person is not to be 
allowed back in to the series. In that case, use the 
same logic" but replace the "B : START" witfc "F: YOU ARE 
NOT ALLOWED TO START AGAIN. C: FINISHED" . This frame 
must also be the first to be executed after the team 
has been assembled. 

Case 3 might "be where the entire team should 'resume 
approximately_where they left off in the previous session. 
In this case, the above special Decision frame would be „ 
interspersed frequently throughout the lesson sequence 
aX every reasonable restart point, and with different 
test numflbers for each and every occurrance of the frame. 
.However, instead of "B: START" , the branch would be to 
"B: ASSEMBLE" which would execute a sub*-lesson module 
to reassemble the team before retusaung to the next 
•frame. In this case, the same sub- lesion^can also be 
called at the beginning. • 

■ X ■ 

t 

Team Initialization Example ; This example will be for 
a ' three-member team, the positions of which are designated 
RED, YELLOW and BLUE. Re-initialization starts over - . • 
Data are allowed to accumulate- from .session to session, 
and from team tb team, #rie first four entries of the 

. j H ■■ ■ 



Common Matrix are used to control the participants. The . 
remainder are available for other sues* A . 0 



FRAME 1.00 *(D.) r 

o 

G2. CRITERIA ' * • " ✓ * 

C:SET MATRJX(X,100) Cr^FETCH X » 
IF SYNC(X(D,X(2),X(3) ;0) EQ 0 v 

,C:X(I)=50 F0R(I=1,'3> , . » 

IF X(4) LQ OfcCfXfO*X . ■ * . 

IF X(I) NQ (TF0R(I=1,3) 

F: SORRY, ALL POSITIONS ARE TAKEN. ANOTHER TIME. C: FINISHED 
ELSE C:X(4)=1 C:PUTfX F:@ARE YOU RED, YELLOW OR BLUE? 

FRAME 2'. 00 (Q) - 

G3. ANSWERS . '. 

0 KEYWORD' ON- v - ' 

A RED . - 

B YELLOW r 

C BLUE 



G4. ACTIONS 
A C:SET COLOR=l - ' 
B C:SET COLOR=2 

C C:SET COLOR=3 - ' 

- R: ANSWER ONE OF^THE THRE-E, QR TYPE 'FINISHED'- 

♦ ■ • 

FRAME 3.00 (D) 

G2. CRITERIA - ' % 

C: FETCH X 

IF X(COLOR) NQ 0 >» \ 

F: SORRY,' POSITION ALREADY TAKEN. CHOOSE ANOTHER. B:2 
ELSE C:X(COLOR)=TERMINAL C:PUT X " ' . ' 

C:SYNC(X(1) ,X-£2),X(3) ;1) B : RED , YELLOW , BLUJE ; COLOR, , 

'. .. ' } 

In the absence of the SYNC command, other .logics.*. * 
could be substituted, which relies on coded, values-, ijtt . v 
the "Common Matrix. However*/ the SYNC command provides 
comparing efficiency -which cannot be matched any other 
■way. * <• ( " '* 



The^ctivitiess.of thQ. participants in- team training 
must interrelate in some manner or" else there, would.. be 
no commonVteam objectives. This interrelationship will- 
show/up in^the lesson; s\>ejiarios as a need to synchronize 
the members' lessons giveavpoints in such' a way that 
they willt all* be at that p6in^at a giv&n moment. 

* ■ There will.be many variations to this need for 
lesson synchronization. In o^ne.' case, similar lessons 
may be moving' the trainee in lockstep fashion, synchron- 
izing again after each* interaction. In another, the* 
synchronization points might be far apart, bringing the 
"members together only at ' checkpoints. Andther might only 
synchronize their • initial departure. / Yet another might 
keep some memfce#« in sync while one or more others drop 
out -to work independently. There may be a need to bring- 
•members ^back %n%o synchronization after they hay,ejbeen 
working independently. ; > i 

v. - . • : -< 

The SYNC** command is designed to fulfill all of ++ . 
•thetab %ove needs and a few more. Essentially,- the SYNC 
command needs only the terminal identity of the partipl> 
pants~and-a synchronization number to define its operation. 
In addition, it needs to be informed when a member , should 
no longer be considered in the synchronization processing 
for some indefinite period of time. A zero (0) synchroni- 
zation number serves this function. 

The command format for SYNC** ,has already been shown. 
Using that format, any two or more PLANIT users whose 
terminal' identities -are named in the SYNC** -command will 
be forced into* synchronization at the point where the 
synchronization nSirib€rs from all of the participants 
agree. In the event that SYNC commands are encoun- 
tered which -are different from others'whach have already . 
been posted and are waiting^ the highest posted * number (s) . 
will 'continue to wait and any which -are less than the t 
highest will 'continue tfc execute. 

/ 

There is no need for any similarity to exist among ,« 
the lesson sequences from which -the SYNC** co.mmand is v 
issued. Synchronization is based entirely ,on the' synchron- 
ization. . It. is the responsibility pf the author tb make 
the fit between the cprrespondihg lessons reasonable. 
The reason could be none other than assuring that all 
finish at about the same time. 0r.it could be for the 
purpose of. exchanging 'data-, responding to events which 
are dependent on the progress of another member or 
^whatever. 
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Establishing Synchronization . ' The first consideration 
must be the initialization of those data items which 
wil«L be used to '-control progress through the Tessons. 
At a minimum, the members must be assembled into a 
team relationship and each members lesson must be 
given the terminal ident^y of the other members so 
that synchronisation requests can be made for the 
proper group of terminals and any desired communication 
\ * can be addressed- to the proper destination. The second 
consideration will be assuring that the proper team 
members (and only that number with no duplicates and 
none taissing) have )?een assembled and £he team, exer'cise 
is. ready to begin. 

The example just shown contains all of these 
elements* This section will simply elaborate on the } 
synchr onization aspects of that example, and discuss/ . 



^ additional synchronizat ibn v considerations* 

The first use of the SYNC** command contains a 
zero (0) synchronization "number (which has been defined 
to mean that this terminal is dropping its synchronizing 
relationship with the remainder ofVhe team). However, 
in this case, no synchronizing relationship is yet assumed 
to exist so the zero (0) parameter has no effect. But * 
therQ will be a return value from the SYNC* * call that 
will be important in that it will reveal whether any 
other mejnber has reached a SYNC** call with a positive, 
non-zero synchronization number, waiting for others to. 
catch up. If so, the Return value will be that^number 
and the lesson will have determined that the current 
member is not the first of the team* to sign on. Otherwise, 
the return value will be zero (0), allowing the lesson 
to make any initialization necessary prior to the assem- 
bling of the team. Therefore, this call can serve an 
important team initialization function*. 

When the first SYNC** call is encountered "with aA 
non-zero synchronization number (as in Frkme 3 of the \\ 
- example), the PLANET system can evaluate the status ory 
' • each of the identified terminals. If they, are not yet 1 
In team status, PLANIT will ask the user, 

• TEAM MEMBER MISSING. DO YOU WANT TO WAIT? (Y/N) . 

If the answer is "Y", that terminal will be held until 
all of the othar team members encounter a similar SYNC 
call in their own execution, and the last to encounter 
it would unleck the%xecution for all participants. «• 
It will be clear t&qxiy who study the example in detail 
that only # the last member to sign. on will have the 
correct terminal i46ntities for all of the team members! 
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"However;-- this will .'not pose a problem for the earlier ones 
because PLANIT will detect the improper terminal 'number 
and use that information to decide that the member is» 
missing. When the last member signs on, PLANIT will - 
tiy&fi have/all the correct terminal • numbers so that the 
■^Crrect synchronization check can be made*. 



Therefore, this provision in the SYNC** feature will 
enable PLANIT to^autjQmatically collect the team members. 
Notice that it will also detect if one should*leave the 
team exercise by signing off without first notifying-- the 
other members. This will avoid' the prospect of team 
members, waiting in frustration .for another member -to-' 
catch up who is no longer on the system. 



Maint aining Synchronization . It is simply a guarantee 
within the. PLANIT system that wherever a SYNC** .'call is 
made in the lesson, execution will not>pass that point ; 
until the lessons of all listed terminal numbers have 
made SYNC** calls with the same synchronization number . 
or at least -one- has made* a SYNC**, call with a^ higher ' 
synchronization number. There is no restriction about 
the nature* of ~th& lesson out of which the SYNC call 
is being -made. " f heref ore . any lessons can be synchron- 
ized* at any point. . t ( ^ 

?*•'•**•'" ' * 

Leaving The Team Temporarily . 1 1 , has alrea'dy' been , 
shown that one can be temporarily dropped from the _ 
synchronized team relationship by making a SYNC call 
with a synchronization number of -zero (OK Actually, J 
this call has no effect on the execution "of the 
lesson that makes the* call; execution continues as 
"though nothing had happened. The purpose o«f the call 
is to mark that terminal so that others who are m 
a ' synchronized team relationship with it will not be 
waiting for it -to. catch up (i.e-. to make,, a SYNC call • 
with the liighest posted synchronization number). 
Instead, that terminal will be drop^d from synchronizing 
consideration even though' that germinal number appears . 
in the.lifft of another SYNC** call: 't Thus, the person < 
at' the terminal can proceed independently without holding 
up other team members, . and will 4, do s d. until a-SYNC 
call is made. from. that lessen with a non-zero synchron- 
isation ^|umber. " "'..*, 

Pa-Establis hing Synchronization With T he Team. This can 
be done very simply by, issuing a. SYNCT* call with. a non- 
zero synchronization number. If • the number is. less than 
the highest existing one, then all will wait for this . 
one tcwcatch pp. If the given synchronization number is 
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the highest, then this terminal will wait ,for the others, 
to catchy up. * - \ > 

• * 

Howevfer, it is fair to. assume that the team will 
have progressed by an unspfci,f ied ^amourrt^while the one # 
member was working independently, and it may v be more 
important to rejoin- the team at the point where execu- 
tion* would normally have been had he not dropped out 
of the team. In this^caseV a list of frame numbers cor- 
responding *to synchronization numbers will make it pos- 
sible to immediately rejoin, the team at exactly the right 
place. For example, suppose 'the array , . SYNCNO., contained 
a frame number for each synchronisation number, where the % 
synchronization number wag an integer ,to be used as a 
subscript into the- array. Theii, the following statement 
would put the member back irrto the team at the - right point: 

B: SYNCNO (SYNC (X-(l) ,X(2) ,X(3) ;0)) 

The example shown above 'assumes- tfiree members in the team 
whose terminal nufnbers are the, first, three entries of 
'array X* It' would also be possible to use the frame 
numbers as the synchronization numbers. Then, no SYNCNO - 
array would be needed; the statement would be simply: 

B:SYNC(X(1),X(2),X(3);0) * 

Notice that the return value from that SYNC** "call will 
mark the progress of the* team. 

ite-Synchronizing The Entire Team . There may be situations 
where a team exercise is not finished in one session and 
all team members sign off with the expectation .of resuming 
at some future time at approximately the pointWjjaere they 
left off. If it can be guaranteed that each oiWhe team?, 
members^ will be using the same terminal number when they 
resume ^s in the /prior . session, 'theft. no special provision ^ 
heeds to b£ >matie.' PLANIT's normal features- for resuming? 
the lesson will be enough to handle the task automatically. 
When the next SYNC** call is encountered, each member will 
be -automatically held in place until the' complete team is 
assembled again. . ** 

However, if the terminal numbers may vary from f 
session to- session, that adds a new "dimension of difficulty 
to the problem. It would mean that the terminal number 
values in the Common Matrix will neqd to«be reassigned 
so that the parameters of the' SYNC** call will be correct. 
Otherwise, theye ,could be a call for a synchronizing 
relationship with terminals which are not executing that 
team 'lesson at all. 



The solution -to' this -problem, if it becomes a problem 
can be devised through some control, logic in the lesson. 
One' such solution will^ be illustrated; many more are also 
possible. *' * ' ' \, 

' Assume that LINK(l) is used t,o represent the current 
syiichronization^umber throughout the sequence of 
lesson modules. That would make the the value of LINK(l) , 
continually increase as the lesson progresses. Also 
assume- that LINTtt(2) holds the Resignation of the partici- 
pant's role ("CQLOR" in the previous example). Then the 
following Decision frame, i'f included at the beginning of 
every lesson module and was the" only punchtuated (dotted) 
frame in tbat module, 'would perform the- necessary ^ , 
reassignment of terminal numbers and would reposition the 
trainee appropriately 'in t\4 lesson. (Note that the 
number '78' is'- supposed to be the first synchronisation ■ 
number of this module and the TOPIC array contains frame 
numbers corresponding to appropriate reentry points for 
each of the synchronization- numbers which are within the 
range of this module.) / 

FRAME 1. 00 (D. ) 4 . 

G2. CRITERIA *• . . • ' ' • 

r-SFT MATRIXfX 100) ■ C:SET MATRIX (TOPIC, 50) 

IF LINK(l) LS.78 B:2 " ' - 
ELSE C : FETCH X C: X (LINK £2) ) -TERMINAL w 
■ IF SYNC(X(1),X(2).,X(3);0) OR ,1 mmwm 
F* ANOTHER TEAM ALREADY JN .PROGRESS. C: FINISHED 
/ELSE ft PUT X C:SYNC(X(1) ,X(2-) ,X(3) ;1) 

B.:T0PIC(LINK(l}-77) * H " 

The .values in the TOPIC array would be adjusted to fit. , 
the structure, of the lesson module in which it was used. 
The values ,s 77" and "78" would be changed to agree with 
the first synchronisation -number in the current module. 
Before each SYNC** call in the. remainder of the lesson 
. module, the LINK(l) entry would be -assigned the corre- 
sponding synchronization number. For example:; 

■ • * * 

C:LINK(l-)=78 C:.SYNC(X('l) ,X(2) ,X(3) ;78), 

This lesson logic would eriable the ^automatic reassembly 
of the team where all members would keep their originally 
chosen roles. Their new terminal .numbers will replace 
the previous ones in the Common Matrix, jmd the SYNC 
/ • » i * 
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calls will prevent theitf frcim interrupting another team 
thatrmay be using the lesson, as well as holding them 
in the % firs B t frame until the .entire team has assembled.. 
The author 'can choose , frame nUmber values for the TOPIC\' 
array which cause the team„ members to resume at the x , 
most reasonable place 5 , which may not necessarily be the 
exact place where they previously left off. 

i • 

Placement of Synchronization Checkpoints , Where the 
SYNC** calls are placed in^the lesson modui^s depends 
primarily on th6 don-tent and where it might be impor- 
tant for team members to be brought together in time. 
However, some simple guidelines will be useful, and 
the .examples in the next section will also pertain 
to this subject. ' 

t . , 

If the training lesson "is structured, in such a 
way that all participants execut^Hfft^S 4 a3ire^ess > cm^ 
sequence, then the, correspondence of SYNC** calls will 
be a trivial -matter since each /participant will" encounter 
the same SYNC** call in the s&irie position due to the 
fact of executing the same lessjon. 

% ' ' I T # 
If the subject-matter callis "for participants in 
different roles to execute" separate lesson sequences, 
then corresponding SYNC calls Will tfe placed in the 
different sequences where^the cbn^ex^ demands. SYNC** 
calls correspond i-f the same germinal values are * 
designated , in the list /\nd if the\ same synchronization* 
number value is used. * 4 

In addition, theyeAdlJ be cds^s where two or more 
participants will b£ required to tkke\turns in their 
interaction with the 'training materials. This will 
be/%nf<arrced through pr©per u&e. /of v corresponding SYNC** 
calls. In general,*it will require two sets^of corre- 
- sponding S^NC** calls to enforce* a "turn,. 11 The partici-^ 
pant who is waiting will ex^ute .two SYNC** calls in - 
immediate succession,* one to* inaugurate the other's turn, 
and the next to "ho^ execution until the other's turn has 
completed. 'Meanwhile, the other, participant will -also 
^counter two- similar SYNC**L calls but trifey will be 
separated to bracket the lesson logic which will govern 
the activity during his or her turn. A sample of this 
kind .of logic appears in the example which jfs included 
in the next section, where the "turn 11 shifts from one 
participant to the other,- as indicated -by the three 
sets of corresponding SYNC** calls. - 
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LESSON STRUCTURING 

Lesson structuring is intended to refer to the 
number and organization of lesson modules to be used . ^ 
in the complete training package. 

Many of 'the lesson structuring decisions will be 
a simple matter of , author preference.' In general, 
considerations which go /into. any PLANIT lesson struc- 
turing process will "be true of team lessons as well. 
Lesson modules are often chained in order to obtain the 
total number Qf frames jdesired, which normally exceed 
the total number allowed in a single 'lesson module. 
"Another common structure is where each lesson topic is 
.contained tn a' lesson module (or series of modules)- and 
these are called, ali*ost in. table-of-conteats tfashion • 
-from the s'upervislng lesson module. .This method is 
particularly efficient if pretest questions are included^ 
in the siipervisorVjLesson to first determine whether the. 
traine/needs to flVprpve in the areas covered by the , 
sub-module. • These^are decision factors whjch. are true - ... 
of all PLA&IT lesson-writing efforts. . ■ 

A few additional considerations- are*present for 
authoring team training scenarios in this'matter. of 
lesson structuring. The decision factors af f ectmg.how 
the modules are to be structured deal mainly with the 
nature of the role tb,at 'each of the -participants plays.. . 
If the various rd*es are substantially different" it is 
usually advisable to form separate lesson sequences for 
eaoh role (as was shown in the previous example). Note 
however that the sequences must all begin in a single . . ^ 
lesson module and branch from there in order to retain 
a common identity for the Common Data Space,. On the other 
hand, if- any of the participants perform identical roles 
(or very nearly so")', they may share the same lesson modules 
If role differences' are minor, "tests can be made in- the 
scenario to differentiate the roles, such as: 

IF COLOR ]£Q 2 Do something special for C0L0R=?2. 

Very many such tests would soon make it .more efficient 
to separate the lesson modules by role, especially 
because of the rate at which this, would consume frames 
plus the added inefficiency of having to execute the 
test. - • % ■ ■ 
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Conditions Affecting Data, Transfer In The Lesson Structure * 
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There are only- two kinds of dqjta which can be trans- 
ferred between leS^bn modules,. LINIUarray data and Common 
Datu^Space data (Common Matrix Common REPLY** Buffers). 

The LgNK array , usually dimensioned' at 10 elements 
(which can be changed at installation time) , contains the 
only data which follow executibn from one lesson module 
to another. This is true in all PLANIT applications/ 
not v gust team training, Hpwever, ;the LINK data only 
follow a single* trainee. E^ch trainee has a different 
copy of LINK which move^ from module to module with < 
jution. If a LINK entry is -changed in one * 
will* retain. that new value in all subsequent 
modules , unless. it is changed again. That value will not 
appear "automatically \n another , trainee T s LINK arr^y * 
though..- * * ' 

s . . ' « 

v> „ Another feature distinguishes the- LINK arsay, o 
* making it useful^ for special applications. • The LINK 
entries are the only* origii^ally-deijined named entries 
which can receive different values (as compared fpr , v „- 
example to FRAME, TIME, RE&PQNSE and PI, which receive 
their values only internally in the system) . Therefore, 
a. LINK, entry is very useful, for an indicator variable. 
. -For .example, suppose there is a need to determine whether," 
. execution has passed a given point.* A sample use of LINK 
ifright be:c 4 

• \ ' ' . * 

\ FRAME 1.00(D) ^ , ^ . , 

-IF LINK(l)" NQ 0 - Execution has passed this point before. 
ELSE" X C: LINK (1)=1 >*r~~ 
Execution has not passed this point before. 

;0£ course," this e^aiitple 'assumes that JLINK(l) has not 

bereri changed from its initialized zero^value prior ito 

this frame. Note that this test would not" be suited 
to a uSer-defined name because oh the first enqounter 
qf that name the fact that it had not yet been declared 
would make the lesson 9top, showing an error. And, x 
declaring the name' in a prior lesson would* not carry 
forward to this one. Thus, LINK series this function 
quite well. 
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The Common Data Space (composed of the Common Matrix 
i akd Common REPLY** Buffers) serve a different function 
from the LINK array, primarily because that data is . ' 
available to' all members of a team regardless oi the 
Ifessbn module that happens to be executing. Recall that 
the definition of members who belong to a single team 
encompasses all who have begun the^training sequence 

• through one common' lesson module wherein the Common • * 
Matrix and Common R'EPLY** Buffers were first ,PUT info 
the Common- Data Space. < „ / 

Another important difference between the' LINK 
array and^-the Common Data Space is the fact that 'the 
entries in that £pace are never manipulated by the lesscfn 
or user. Rather, a local c6py of a matrix or JRE?LY buffers 
is PUT into that space, overwriting whatever was currently 
there'. If the values are to be examined or updated, they 
mus't first be FETCHed-and then be PUX back again (in the i. 

. case of an update). When updating, the FETCH £nd PUT 
should occur in 'the sam^ group of a single frame with 

* no intervening opportunity for delay (such as a terminal., 
input request;. If that guideline is followed, PLANIT' 

* contains' provisions whicK will. inhibit any other user ' , 
'from interrupting the FETCH-PUT sequence before the 

' update has been completed. The data arrays in the 
Common Data ^Sp ace are" unnamed ^ and therefore, not referenced' 
by name. The name to be used after the FETCH and/ or PUT 
will be* a local name only, 'designating the loca^l copy 
within which the work will be done. . * 

.Thus the Common Data facility allows data to be . 
moved freely among participants in the team. The author 

. must take into consideration the fact that^the entries* 
in that Common Data miglft be changed in different ways 
by different participants. For example, -Suppose that . 

, the first entry (e.g. X(D) were set aside tq - hold r the 
terminal number of the participant and there were three 
participants. Then the first entry would finally hold 
only the terminal number of- the 'participant who most Km 
recently updated it. This is in contrast to LINK(l) , , 
'which will remain unique for each participant. It is* * 
for this reason that the prior Vxample -usfes the item 

>• "COLOR" to subscript the data from the Common Matrix 

in order - to .distinguish each Qf the participants. r 

. . . ^ ' * <. 

Note that the possibilities for using the Common 
Data seem almost limitless. . Numbers which are PUT by 
. one team member can be FETCHed and* fcsed to affect the 
execution of another. Prior tp the addition of the &YNC** 
command, Common Matrix codes were used to synchronize 
* N *' 
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team members in much the same way as the synchronization 
number does -in'SYNC**. . A Decision fxanfe tests the code 
numbers in "the Common MatrixLwhi<^i were PUT there by each 
of 'the participants and holds "each at that point until' 
all the numbers agree. * ^ * , 

* . o 

In the case of the v Commoh REPIjY-** Data, combining 
that wfrtii the SET REPLY .and -USE REPLY commands, enables 
the passing of charact^i strings for almost any purpose 
whatever, fijom simple n^^ages to having one participant 
respond to another p^iric|paivt T s questions. /It would 1 4 
even be a simple matter to have one participant execute * 
tyr<6 or more different lessons concurrently, passing tlie 
responses through the CojnraOn REPLY** Buffers... Jjfessages 
sent from one to another could "be; examined altftig the 
way and the' identity of the contenC^fcouldHtje stored ^ 
along VitA the student records'. ThiS* variety possible 
makes examples very difficult. Lfc-fe*s chopse the, case 
where one 'member 1 s lesson asks a 'different member to # - 
respond to one of* its questipss, e\Stluates .the response • 
and provides feedback to both ^lembfrs. Suppose the 
originating member i£.R*ED*and tja^ o<Rier ' member* is BLUE. 

The implementing lesson sequence for RED will be: * 

• 1 * * • 

FRAME 10.00 (6) 

F:BLUE>IS BEING ASKFjD, WHAT YEAR COLUMBUS SAILED WEST TO 
Ft FIND INDIA, WAIT k MOMENT UNTIL BLUE HAS GIVEN AN „• 

F: ANSWER. , . > »V * 

C: SET REPLY (1)= * WHAT YEAR DID COLUMBUS SAIL WEST TO. FIND INDIA? 
C:PUT REPLY' C:SYNC(X(1),X(2);10) CVSYNCCXCD ,X(2) ;H) * \ 
C: FETCH REPLY C:USE REPLY (1) + 

FRAME 11.00 (Q) 

- G3^— ANSWERS . : 

1+ 1492 

•G4. ACTIONS ' 

FrBWJE'S REPLY, "$ 

C: PRINT REPLY (1) $F:" WAS $ 

F: 

1 C:SET REPLY(1)='RIGHT. ' C: PUT REPLY C:SYNC(X(1) ,X(2) ; 12) 

- C:SET REPLY (1)= 'WRONG. ' C:PUT REPLY* C:SYNC(X(1) ,X(2) ; 12) 
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The corresponding implementing sequence for BLUE will be: 
*~ * * * . 

-\ * > ^ 

FRAME 20.00 (D) , * 

G2. CRITERIA 

C:SYNC(X(1),X(2);10) F:Y0U WILL NOW GET A QUESTION FROM RED. 
C: FETCH REPLY C: PRINT REPLY (1) / . 

FRAME 21.00 (Q) . ' " 

G3j. ANSWERS • 

A • DUMMY " ^ ' 

G4. ACTIONS- • - • / 

C : SET/REPLY (1 ) C : PUT REPLY C : SYNC (X (1) , X (2 ) ; 11-) 
C:S&flC(X(l) ,X(2>;12) C:^ FETCH REPLY C: PRINT REPLY (1); 

One jipssible executioiT sequence iwould be (assuming 
that BLUE gave" the correct answer): 

RED's .terminal : , , ; 

BLUE IS BEING ASKED WHAT YEAR COLUMBUS SAILED WEST TO * 
FljHD INDIA. 'WAIT A MOMENT UNTIL BLUE HAS GIVEN AN 
ANSWER. , > 

BLUE'S REPLY, "1492" WAS RIGHT ^ 

BLUE's t erminal : 
' 5 

YOU WILL NOW GET A -QUESTION FROM RED. 

WHAT' VjEAR DID COLUMBUS SAIL WEST TO FIND INDIA? - 

\ . . * . ^ 

1492 , . ' \ ? 

RIGHT. 

• Notice the use of the SYNC** commands. They define . 
-the points at which the lesion, executions must be>synchron- 
ized in order for the sequence .to come out correctly. The . 
three synchronization points can be described as follows: 

SYNC Point* 10: Waiting to start the sequence • together 
at which time BLUE will receive the 
question arid be given time to answer. 

' s4kc Point 11: Waiting for BLUE to answer at which 

time RED will evaluate' the answer and 
" set up a feedback message. 
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SYNC Point 12: Waiting for RED to set up the feedback 
message at which time both RED and 
BLUE will continue their respective 
lessons. ' H 

This same sequence could also be implemented using 
only number codes ^±n .the- Common Afatrix^but with much more 
lesson logic and requiring several times as much computer 
processing time. Using the above example, the computer 
processing time will be little if any more than each 
executing independently # ' • - \- * „ 

Note in the above example that BLUE r s response, "1492 
will be recorded in RED's student record in the frame 
number 11 entry. It would havp. been easy to h^ve it also 
recorded in BLUETS student record by changing the Grcfup 
3 entry of; Frajne 21- from "A • DUMMY" to "1+ 1492" asrln 
the RED Frame "II. However, that would suppose that the 
BLUE lesson was aware of the particular question that 
would be asked, m?tking the whole exercise much legs* 
meaningful. Suppose, on the other haj&d, it was important 
"for the BLUE lesson to record that response and did* not , 
know the question in advance.- That would s/till be quite 
possible by adding another Question frame t'o the BLUE 
lesson such as follows: * / 



FRAME 22T00 (Q) 



G3. ANSWERS 

0 USE SEPLY(l) 

A+- RIQHT. 



i 

This would simply evaluate trfe feedback from the REDk 
lesson, and then. th t e student record for Frame 22 
would contain the right/wrong information for the response 
in Frame 21. 

It soon becomes obvious that there can be few "panned 1 
sequences for desired operations. Rather, the operation 
£tself must be Examined ' aTnd the sequence~TsT developed 
accordingly. v 

These same kinds „ of interactions can also take place 
with larger teams of three, four, five, 'etc., members but 
the* complexity r of; the synchronization 1 * can grow t tod. Tike 
subject or synchronization has already been discussed in, 
the prior section. • . 
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Inter-Terminal -Cpmmunication 

IrJJ conventional CAI , ^nter-terminal communication 
is seldom considered to be a factor of the lesson . 
structure since any inter-terminal communication is * 
usuallv incidental to the lesson* conte&t. However, ^ 
inter-cerrainal communication in^a, team training* context 
will often-be^an! integral part St the lesson structure, 
content and /Strategy. „ - 

0* * . ' * \ 

Inter-terminal communication can be expedited in 
two way's, directly through the DIAL command and indirectly , 
through the Common Data Space. In^the case of thej^efmmon 
Data Space, the communication can be free-form through' 
the SET REPLY (n) and PUT REPLY** sequence in one lesson and 
FETCH REPLY**, and PRINT REPLY (n) in the otiiefr, or it Vn be 
a prepared message list, passing only the^message mimaer 
across- terminals and using that to> display the desired 
message* 

Several considerations - will suggest the most appro- 
priate method to use v First, the DIAL command is immed- 
iate. . There is no provision to time the displfey of that 
message at the target terminal to- correspond with the 
execution* of thsvt lesson.- SY^ci^-calls strategically 
plaoed could introduce that tiMng-bowever. 

Second, there is no provision to allow the examination 
of the Qontent of the DIALed ^message by either, lesson. 

Third, using the DIAL, the desired message, must be 
prefixed by the appropriate command form, and enclosed 
-in primes (or quotes) . This will be true whether the 
message originates 4 yri thin the lesson oir in real time by 
the trainee. , * A 

Fourth, the DIALed message automatically carries a * 
n FROM n" prefix* t$ identify the source of the message. 

Fifth, the. DIALed message has very little impact 
on execution. time* t % J 

-Sixth, using .the REPLY** buffer J^cility, .messages 
can be sent which are subject to examination prior to 
transmission and/ or' after reception and display. They 
can be identified -as to their source, or not, at the 
disck*etion of th* author. They can be transmitted and 
held until the receivers ready for them, or SYNC 
calls can time the sending and receiving (as in the case 
of <the DIAL). Since the communication is through. disk 
blocks, there will be modest impact on execution times ' 
in the lessons. 
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If trainees are to s.end messages, through the REPLY** 
buff ers^J * Question frames must be designed to collect and 
,send the message and more lesson logic must be prepared 
'on the receiving end to retrieve and display the, message, 
whereas the trainee can sen£ a 'message ~via DIAL outside 
the framework of the lesson and it will be displayed 
at th^4£hex end without the need for advanced preparation, 
v ' ./ . , \ 

Finally, there" might T^e a need for sending the message 
fj/om the trainee to the lesson, to*be retrieved and 
displayed by -the author at the end of the session along 
with other-performance data. This can be accomplished 
by holding the message (s) in the REPLY buffets of the 
individual "student records (without- executing a PUT 
\ REPLY**) . Each participant would have separate REPLY 
space. * However logical problems could develop if that 
strategy was^ombined with PUT REPLY*** and FETCH REPLY** 
sequences since the buffer areas would be written over 
by oi/her data. ' \ 



Whether the DIAL or REPLY buffer method is used to 
convey messages between terminals will depend on the * 

""particular circumstances of the message. Typically, if 
the purpose of the exchange of messages is for an un- 
monitored.cbnf erence, the DIAL facility is most suitable. „ 
However, if the message must coincide with lesson * ■ 
execution at both terminals, If it must reach its proper . 
destination Without expecting the sender to put the 

-address prefix on it (DIAL n.) , if it is to be enqueued 
and held until the receiver calls for it (or, it is called 
for by the- receiver f „s lesson logic)', or i^ it is to be 
examined' by lesson logic prior to transmission and/or 
following reception^ then the REPLY** buffer method is 
appropriate. * 

Examples of Two Message Transmission Methods . The . 
following twQ examples wi^.1 illustrate the sending • 1 , 

and receiving logic for the- DIAL and REPLY** buffer / 
methods bf message. transmission. 

¥ - 

Trainee-Originated DIAL message : 
— — — w ■ } — — 

.♦DIAL- 3 'THIS IS * THE MESSAGE. • ' 



Lesson-Originated DIAL message ; > 



:'-C:DIAL 3 'THIS IS THE MESSAGE. ' 
* ♦ 



' , deception' of the DIALed message : - 

FROM 3 THIS IS THE MESSAGE. . ( * ' \ 
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•FRAME 4.00 (Qh 



Trainee-Originated REPLY buffer message ; 

TYPE YOUR MESSAGE TO 'RED, 1 » . * ' 

G3. ANSWERS ) . * . . 

A DUMMY : \ ■ 

G4. ACTIONS * . „ • 

C:SET REPLY (1) C:PUT REPLY 

Lesson-Originated REPLY buffer message ^ 

C:SET REPLY/(l) = 'THlS % IS THE MESSAGE.' C:PUT REPLY 

Reception of message in- the REPLY buffer : . 

C: FETCH REPLY C: PRINT. REPLY (1) 



f 



. Notice in the last line of the_ examples that a -delay- 
is possible, both before the REPLY buffer is FETCHed and- 
before it/i,s displayed via the PRINT command.* Thus, the 
message could be queued, examined, modified, or whatever 
before the receiving party sees it. In fact, there- 
may be no intention of displaying the message but .rather 
to subject it to. some other kind of processing as in . 
the example on pages 26 and 27. 



LESSON MAINTENANCE 



Team'lesson applications add very little to lesson, 
maintenance wh^ch does not 'already apply to Conventional 
\Lessons. The main difference is in regard to the 
Common -Dat 3, §pace, and the manner in which the dat£ 
there are to be used. 



Setting The Lesson Up For Exe^utiQn 

The easiest way to • initialize data spaces is to 
make the lesson expect them to begin with initialized^ 
values tif zero (0) (or "null 1 !, in the case of ; the REPLY 
buffers). At most, this only requires the declaration 
of that data. However, lesson needs may dictate data* 
entries which, in their initialized §tate, have a whole 
range of values. If the data are to be local to th$ 
lesson^ module, then the initialization logic must be at 
the beginning of each module in which it is being used. 
But, if the data will be, kept and manipulated in the 
Common' Data Space, then initialization of that data 
can be performed more economically in a special lesson, 
mo.dule. However, if a special 1-fcsson module is to be 
used .f 02: that purpose, it' is important that the author 
must sign on to the same beginning le'sson module "that 
the team members do so that the proper Corakon Data « ■ 
Space wiLjL get initialized?* 4 

A place t that is often convenient for doing this" 
Common Data initialization is within f the beginn ing 
•lesson module itself. The^lesson or gan i z at ioh- 
kept tidier if the^first lesson module contains only* 
that part of the training scenario that assigns parti- 
cipants to their respective -sequences, as shown in -the 
example on page 16. If that strategy is adopted, then 
that\first lessor! mobile will be very small. 

' * > » ** 

Suppose that first lesson .were extended, beginning 

with 1 Frame number 4, whe^e* the frame was given some , 

label of- the . author T -s, choosing which would serve as a 

special password for lesson maintenance. % Recall that 

the lesson does "not automatically execute f or 'the , 

author as it does for a trainee. Therefore, the # 

author can GET the lesson by name, and then give the 

command, 1 

. * - 64 - ' , 
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EX. PASSWORD 

where PASSWORD can be any label name that the author 
has chosen to direct* execution to the extension- of 
that lesson module*. Al£o note that, due to the • execution 
logic, there is fvp way for the trainee to enter that 
portion of the lesson module* 

/ The author is now free to develop^ as much lesson 
logic as necessary to initialize the lesson data as * 
it is designed to be. The example below illustrat.es 
such a plan. 

* ° 
Data Readout Following Team Execution 

The same method that was suggested *for setting up 
the data requirements in team lesson's, in the paragraphs- 
-above can also be used to display the) pertinent data 
following the team exercises./ The following example 
will illustrate this aspect 1 as well 



J. 



Example Of Lesson Maintenance Frames 

This example is meant as ; a continuation of the 
beginning lesson in the team 'training sequence such 
as was illustrated on page 16. ~Note that the author 
(and only- the'' auth«r) can «hoqse to display data only, 
display and ini^aliz'e/the data, or initialize the 
-data only. This sequence can obviously be tailored 

to suit local needs. 

f ... 

> • 
FRAME 4.00 (M) LABEL=PASSWORD 

• __ 
■s - ' » 

G2, TEXT * 

DO YCTTWANT TOr , * , .- 

G3. ANSWERS 

A. DISPLAY ONLY ' . * ' 

B. ^ DISPLAY -AND INITIALIZE 

C. INITIALIZE ONLY * 



G4. ACTIONS 
C B-.INIT r 



FRAME 5.00 . # . * <> 

* 

• This frame, or series of- frames, will be designed 
to FETCH and display the appropriate "data in any report 
form chosen by the logic*. Tfie frame (5*00) was not 
further identified because it. might be a Decision frame ' 
which contains statements for declaring, FETCHing and 
printing data^ or it could be a Question frame to 
provide choices among alternate display formats* 

Remember that prior to the' FETCHing of a €ommon . 

Matrix/ a local matrix must "be declared into which ■ 

the Common Matrix values are to* be copied, and-, even 

though: such a matrix, is already 'declared in Frame 1 

of tfris lesson, the author will' be bypassing that 

frame so another declaration must be provides! li^e, e.g. 

• • * f * 

C:SiT MATRIX(X,100) t C : FETCH X \\ * . 

" % Nov/ to contihue the example beginning at sonte 
frame number pas*' the display section. 



FRAME 10. 00 .(D) LABEL=INIT 
IF 4, A C: FINISHED 
\ ELSE 

Beginning at' this point, the lesson" logic is 
now writ'lfen-to perform any initializatipns desired. 

,R£qall again that the data declarations in the 
display section (Frames 5 through 9) • could be bypassed 
, if tjie author chpse to "INITIALIZE ONLY." \ Therefore, 
the data ought to be declared again. If there was^ any • 
objectiqn to declaring the data in both sections ' » 
(which is completely satisfactory although perhaps 'not 
1fhe most elegant), then all the data declarations, coulc^ 
be made in GroujX4 of Fram^4 (L*bel=PAS SWORD)', ahead 
of the "C B:INIT f \ statement. ^TJlat would declare all 
the necessary data spaces ^o^eitAer or poth of the 
following sections. * _ — I " * 

Note that the test keing made 'i ft Frame 10, befor'e 
initialization proceeds, is to teTmirtate execution in\ 
•the even* that the author* requested choice "A. DISPLAY ^ 
ONLY", designated by the characters "4, A" in the test. 

After the initialization has been completed, the 
final 'statements PUT the data into the Common Data ' 
* Space and the training sequence is ready for the first * 
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Choosing The Proper ESCAPE Parameter Value 

The ESCAPE** feature is designed to log off any 
user who exceeds a' specified number of computer 
processing secpnds without an intervening input at 
' ♦ the terminal'* It will nonrSlly'bfe rare that the 

author will ever be concerned with this command. Yet 
' it^is there to protect against the kind of infinite 
\ loops- that improperly designed lessons '.(especially ^ 
teain lessons) sometimes originate* ^ 

> If the ESCAPE** value has been exceeded, the'" 
user will be adequately informed at the terminal before • 
being logged out. It will then be the responsibility 

• <pf the author to determine whether the lesson contains 
/legitimate processing demands which caused 'the condition, 

• to occur or whether the* lesson is not, functioning 

• properly* This can be determined by using the various 
. ' debugging aids in PLANIT; such as "TRACE* ALL 11 and 

/-'BREAK." 

, 0 If it has been determined that the Wesson is 

executing properly, then a statement will need to be 
. added to increase the value of the- ESCAPE** parameter. 
' - The format, for this is completely analagous to "WAIT". , 
The following CALC statement: 

' ESCAPE (n) * 

Vhfere "n" names a value for processing seconds , increases 

,(or decreasfes)' the limit for the next single interval of 

time beginning with the next terminal input.- The 

corresponding statement: 

'/ • * 

SET ESCAPE (n) 

changes that limit for-\ll future tirminal response ^ 
intervals in m the -current lesson, or until another ESCAPE 
command is executed* 

i 

If the ESCAPE** liliiit has halted lesson execution, 
. ' , one should not immediately assume, insufficient Aexecut ion 
time unless the* lesson logic is known to involve long 
Sequences of computation* Team lessons in particular 
seem to involve complex monitoring and simulation- 

iterations where simple mistakes can inject the lesson r . ^ 

into ,atn infinite loop* • 
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APPENDIX C 



: * • DjfiMONSTlfrATION TRUCK RENTAL LESSON 



1 FRAME 1.Q0 CQ.) *• 

2ARE YOU THE FIRST OF THE PLAYERS TO SIGN ON? ^ 

3/POSNEG/" * , 

4^CtSET NUM=4 C:SET UPDATE=3 C:SET MULT=20 

4 C:.SET MATRIXCCOM, 13+NUM,2) C : ROUND 0 - C:TRACE OFF 

A C: CHANGE ABSOLUTE TO ABS C: CHANGE TRUNCATE TO TR 

4+' C:PUT COM F:OK* INITIALIZED FOR A NEW GAME. .' 

1 FRAME 1.50 €D> 

2 C: FETCH COM' * * 

21 F PROD C0MCI>1) FORC I = LJ> NUM+ 1 2) NQ 0 

2F:S0RRY, ALL COMPANIES ARE TAKEN. TRY LATER. C : FI NI SHED " 

1 FRAME 2 ."00 <C) . 

2D0 YOU WANT TO SEE THE RULES FOR V THE GAME? 

3/POSNEG/ 

4- B:5- * .... . 

1 FRAME 3.00 C'Q) ' * ' • „ 
2Y0U HAVE -A TRUCK RENTAL COMPANY WHICH SERVES FOUR CITIES, S 
2INCLUDING LOS ANGELES C LA ) j SAN FRANCISCO ( SF) * ' PORTLAND (PO) S 
2AND' SEATTLE (SEA). YOU START THE, GAME WITH YOUR TRUCKS $ 

2DI STRIBUTED AS FOLLOWS:© -. SEA — -20© PO -15. 

2 SF - 3S€ LA 50 . 

2©Y0U CAN SEND THE TRUCKS AT ANY TIME TO ANY OF THE CITIES BY S ; 
2 TYPING ANY TWO OF THE- ABBREVIATED CITY NAME'S CE.G. LA SEA $ 
2MEANS TO SEND THEJPRUCK FROM LA TO SEA). HOWEVER* THERE WILL S 
2BE A LIMITED NUMBER OF FULL -PAYING CUSTOMERS READY TO GO S 
2BETWEEN ^AWj POINTS. THERE WILL ALSO BE SOME WHO WILL BE S 
2WILLItfG TO RENT AT A DISCOUNT (50% CUT IN PROFIT) AND AN S, 
2 UNLIMITED NUMBER WHO . WOULD GO FREE* (YOU LOSE 25% OF JfJORMAL S. y 
2PR0FIT). YOUR FULL-FARE PROFITS ARE AS FOLLOWS: 
• 2 LA SF - S40@ SF PCf - S60© PO SEA - $20 ■ 

2 DISCOUNT PROFITS ARE HALF OF THE ABOVE,, FREE LOADERS COST $ 
2Y0U 25% OF THE ABOVE, AND PROFITS ARE ACCUMULATIVE OVER THE $ 
2VARI0US LEGS (E.G. LA SEA -'• ,5120). 



1 FRAME 4.00 (Q) 

2Y0U CAN SEE v WHERE YOUR TRUCKS ARE CURRENTLY LOCATED BY S 
2 TYPING THE WORD* ^TRUCKS '• _J.OUR CURRENT ACCUMULATED EARNINGS S 
2CAirBE^E^N , ~BY^YPlfilG T^E^'WORiSs* 'NET PROFIT' COR JUST ' NET *1 . ' • 
2Y0U WILL^SEE THE EARNINGS OF THE OTHER COMPANIES* TOO*' S \ " 
2 THUS* THERE ARE THREE ACCEPTABLE INPUTS: 6 1) TRUCKS 

2*2) NET© 3) CITY1 CITY2 CE»G« LA SF) ' 

2QTHE THIRD INPUT FORMAT WILL PRODUCE A REPORT OF THE NUMBER S 
20F TRUCKS AVAILABLE TO BE SENT AND THE NUMBER OF PAYING $, 
2CUST0MERS TO -GO CBOTH FULL-FARE AND DISCOUNT)* THEN ASK 'HO V S 
2 MANY TRUCKS ARE TO BE SENT. CUSTOMERS WILL BE ASSIGNED TO S 
2 TRUCKS AT THE BEST INCOME RATE. . v \ 

2@ THERE WILL BE SEVERAL IDENTICAL RENTAL COMPANIES* NAMED S 
2RENT1* RENT2* RENT3* ETC YOU CAN CHOOSE TO BE ANY ONE OF S 
2THEM. ALSO* YOU CAN DIAL MESSAGES TO ANY OTHER COMPANY S 
2BY NAME CUBING CALC). . MAYBE YOU CAN STRIKE A 'BARGAIN OF S m ' 
2 SOME KIND WITH ANOTHER COMPANY THROUGH AN EXCHANGE N 0F S 
2MESSAGES. DON'T WAIT* TOO LONG THOUGH TO DECIDE HOW MANY S ~ 
-2TRUCKS TO SEND AFTER" YOU HAVE CHOSEN-A • ROUTE BECAUSE ANOTHER S 
2 COMPANY MIGHT GRAB THE PAYING CUSTOMERS FIRST. . . ' 

29YGUR GOAL IS TO EARN AS MUCH FROM RENTING THE TRUCKS' AS S 
2P0SSI3LE. CUSTOMERS WfLL GENERALLY BE MORE READILY AVAILABLE S 
2AT THE LARGER CITIES. YOU MUST TRY TO HAVE TRUCKS WHERE THE S 
J2PAYING CUSTOMERS ARE. HERE GOES. , , • 

& FRAME 5.00 CP)' . . • ' 

'2F:0 WHICH COMPANY DO YOU WANT TO BE?§ 9 / 

2CM = 13 C: FETCH COM • 

2L1: IF C0MCI*1) EQ 0 G* PRINT ' '*I-12*') - RENT'; 1-12 

2IF r LS NUM+12 C:I=I + 1 B:LI 
1 FRAME 6.00 CQ) 

31 NUM/2+.S - WI THI NCNUM/2- . 5) - A 

4-. R: CHOOSE A^NUMBER. ' r ' . 

1 FRAME 7.00 "C DTS 

2C: FETCH COM -\ 

2IF C0MCREfeP0NSE+12* 1) NO. 0> y . - " \ 

2F: THAT COMPANY • I S TAKEN> CHOOSE ANOTHER. B:6 

2 ELSE C : COMCRESPONSE+ 12*1) = TERMINAL C:PUT COM * 

2C:SET PROFIT=0 C:SET MATRIXC TRUCKS* 4) 

2C:SET MATRIXC CHK*NUM) C:SET MATRIXC QUE* 4* 4) , ' 1 Y 
2C:SET MATRIXC EARN* 12) C:SET MATRI XCPRTY* 1 2) 

■2C:TRUCKSC1)=ARRAYC20*15*35*50) C:SET CO=TRCRESPONSE) '-• 

2C: , EARNC 1)=ARRAYC20*80* 120*20*60* 10C& 80* 60* 40* 120* 100*40) 
2C:PRTYC 1 ) =ARRAYC6* .2* . 3* . 5* .4* . 3* . 5* . 5* • 8* • 6* • 6* 1 ) 
2C:SET X=0 C:SET Y=0 CrSET Z=0 

2C: FUNCTION ENRCI)=SUM QUECI*J) F0RCJ=1*3)' " 



1 FRAME 8.00 CO.) 

2TR/){NSACTI0N? 

30 TEXT ON 
3A SEA PO 
3B "SEA SF 
3C .SEA LA 
3D PO SEA 
'3E PO SF 

*< 3F PO s LA 
3.G SF SEA 
3H SF PO 

31 SF LA 

3J LA SEA ' 
3K LA PO 
3L LA SF 
3K TRU 
3N NET 
3P SAN 
3Q LOS 
4A C 



C :Z=2 
C$Z=3 
C : Z=4 



X=l C:Y=1 
X=2 C:Y=1 
X=3 C:Y=1 
X=4- C:Y=2 C l .Z=l 
X=5 .^C:Y=2 C:Z=3 
X=6 C:Y=2' C:Z=4 • 
X=7 C:Y=3 C:Z=1 
X=8 Cs>Y=3 C:2=2 
X=9 C:Y=3 C:Z=4 
X=10 C:Y=4 C:Z=1 
X=ll C:Y=4 C:Z=2 
X=12 C:Y=4*C*:Z=3 
AVBL , v. 
EARNINGS * 

IF YOU MEANT SAN FRANCISCO, TYPE *SF\ 
IF YOU 'MEANT LOS ANGELES, TYPE- 'LA*. ' 



4B 
4C 
4D 
4E 
4F 
4G 
'4H 
41 

4J .C 
4K C 
-4L C 
4M B 
4N B 
• 4P.R 
40. ,R 

47 Rr? - ' - ( ' • 

1 FRAME 9.00 CD,) * ' \ * ' 0* 

2IF TRUCKS CjY) EG 0 F:N,0 TRUCKS AVAILABLE* B:8* 
* 2 END C: FETCH COM * ' . 

2IF. TIME*COMCNU|5+l3, 1) *.6R UPDATE C: COMC NUM+ 1 3J.i 5 =TrME_ 
2C : "COMC 1 i = COHC I * 1 ) +TRC CPRTYC I )YiULT-COMC I , D ) RANDOM) FORC I f 1 
2 C : COMC 1^2) =COMC 1*2) +TRC C/2PRTY C I ) MULT- COMC I * 1) ) RANDOM) FORC I = 
2C:PUT 'COM ' ' - ' \ *. - - 

2ENI).C:TRVC'KSCI)=TRUCKSCI)+QUECI .»1) FORC 1*1 > 4) 
2C:QUECIi J)=QU£CI,<J+lVF0RCJ=.i%3 1 = 1*4) 

2C :PRI NT TRUCKS C-V)'; ' TRUCKS AVAILABLE. S'CQMCX* US' , . 

VbtPRINT • FULL- FARB -AND ^>COMCX* 2)5 ' J5IS COUNT *S ; 
2F:CUST0MERS ARE- READY TO' GO. '-ROW MANY-'" TRUCKS- DO" S * " 
2 F: YOU WANT TO SEND? ' '* • " . • % • 




1 FRAME It). 00 CG) 
31 ASSCTRCRESPONSE) ) . 
4- F: CAN'T ACCEPT THAT NUMBER. B:8 

1 FRAME 11.00 CD) 
~2IF RESPONSE GR TRUCKSCY) 

2 F: DON'T HAVE THAT MANY TRUCKS AVAILABLE. B:8 
2 END C:TRUCKSCY)=TRUCKSCY)-RESPONSE * 
2C t QUEC.Z* J) =QUE( Z> J) +RE6E&NSE FORC J=ABSCY-Z) ) 
'2C:SET N1=RES?0MSE C : FHTCff COM 
2IF Nl-GR C0MCX>1) CsNlVcOMCX, 1 ) . 

2 END C:SET N2=RESP0NSE-^I1 
2IF N2.GR C0MCX*2) C:N2=C0MCX>2) 
2 END C:SET N3=RESP0NSe4n1-N2 » 

2C:PR0F1 T=PR0FI T+TRC CNlV . 5N2- .25N3) EARN C X ) + . 1 ) 
. 2C:C0MCX, 1)=C0MCX, 1)-N1 Vs-S^X, 2) =COMCX, 2 ) -N2 
2C:COMCC0+12;23=PRO*lT 'CrPUTf COM B:8 

1 FRAME, 12.0 OS CD) LABEL=AVBL 
2 F:© CITY AVBL. ENROUTE© — -/- 
2C:ALIGN ^SEA' > 2 J TRUCKSC 1 ) > 1 0 J ENRC 1 ) > 1 8 
2CJALIGN '?0 ' * 2 J TRUCKSC 2) j 10 J ENRC 2) * 1 8 
2C: ALIGN • SF ' *2J TRUCKSC 3) * 10 J ENRC 3) > I8r , 
2C:ALIGN 'LAN ^TRUCKS C 4) > 10J ENRC4) > 18 

2C:TRUCKSCI ) =TRUCKSC I ) +Qy£CI > 1) F0RCI=l>4r "■ 

2C:GUECI.» J)=QUECI, J+l) F0RCJ=1,3 I = 1 * 43 — B-t-8— 

1 FRAME 13.00 CD) LASEL=EARNI NGS « 

*' 2F*@C0MPANY EARNINGS©-- '-- C : FETCH COM 

*■ 2jC:ALIGN. ?>RENT'*2J l,T>*% % > 10J COMC 1 + 1 2, 2) A 8 FORC I = 1 > NUM) 
21 F CHKCI) EG COMC 1 + 12*1) -FORC I = 1 > NUM) B:8 . 
2 END C:CHKCI)=C0MCI+12, 1) F0RCI=1>NUM) 

2F:© COMPANY TERMINAL© ' 

2C:ALIGN , RENT % J 2JI J 7i.G-HKCI),*44 FORC 1 = 1 ,NUM) 

2C:RENT1=C0MC 1 3> 1> . * 

2'IF NUM GR 1 C:RENT2=C0MC14, 1) \ 

2IF NUM GR 2 C :RENT3=C0MC 1 5* I ) 

2 IF NUM GR 3 C,:RENT4=C0MC1 6, 1 ) . 1 * ' . 

•'.2 IF NUM GR 4 C :RENT5=COMc4 7, 1 ) 

2IF NUM GR' 5 C :RENT6=C0MC1 8j 1 d ^ 
2 IF NUM -GR 6 C :RENT7=C0MC 1 9, 1 ) , T 

21 F NUM GR 7 C :RENT8=C0MJ20> 1 ) 

2 END. B : 8 », ■ , 

ssss • 
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f APPENDIX D 



SAMPLE RUN OF DEMONSTRATION LESION 



ARE *YOU THE FIRSJ OF THE PLAYERS TO SIGN ON"? 
*YES* 

OK, INITIALIZED FOR A NEW GAME. _ ' 

•i. * i * » 

. DO YOU KANT TO SEE THE RULES FOR- THE GAME? 

• *YES- , 4 * 

- YOU HAVE A TRUCK RENTAL COMPANY WHICH SERVES FOUR CITIES* INCLUDING LO£ 
ANGELES CLA\> 5AN FRANCISCO CSF)> PORTLAND CPO) AND SEATTLE (SEA). ALL 
START WI7H WS>SAWE* NUMBER -OF * TRUCKS DISTRIBUTED A£ FOLLOWS: 

SEA - 20 

PO - 15 

SF - 35 

LA - 50 

YOU CAN SEND THE TRUCKS AT ANY TIME TO ANY OF THE CITIES BY TYPING ANY 
TWO -OF THE ABBREVIATED, CITY NAMES' CE.G. LA SEA MEANS TO SEND THE TRUCK 
FROM LA fO SEA). HOWEVER, THERE WILL BE .A LIMITED NUMBER' OF A 
. ■ FULL-PAYING CUSTOMERS READY TO GO BETWEEN ANY TWO POINTS. THERE WILL 
ALSO BE SOME WHO WILL BE WILLING TO RENT AT A DISCOUNT ^50% CUT IN 
PROFIT) AND AN UNLIMITED NUMBER WHO WOULD GO FREE CYOU LOSE 25% OF 
NORMAL PROFIT). YOUR FULE^FARE PROFITS ARE AS FOLLOWS: - 

LA SF - $40 • ' J 

"SF PO S60 ^ 

PO SEA'- S20 ' ■/ '- • -- r ^ . , 

' DISCOUNT PROFITS ARE HALF OF THE ABOVE; FREE LOADERS COST YOU 25% OF 
THE ABOVE, AND PROFITS ARE . ACCUMULATI VE OVER THE VARIOUS LEGS CE.G. fiA 
SEA — S120) • . ' 

%0U QAN SEE <WHERE YOUR TRUCKS .ARE CURRENTLY LOCATED BY TYPING THE WORD* 
•TRUCKS'. YOUR CURRENT ACCUMULATED EARNING*. CAN BE SEEN BY TYPING THE 
- WORDS, 'NET PROFIT'. COR -JUST 'NET')., YOU WfUL SEE .THE EARNINGS OF THE 
OTHEH^OMPANIES, TOO. THUS, THERE ARE THREE-'ACCEpTABLE INPUTS* ^ 

1) TRUCKS . ; 

2) NET • 

3) CITY1 CITY2 CE.G. LA SF> 

THE THIR-D INPUT FORMAT WILL PRODUCE A REPpRT OF THE NUMBER -OF TRUCKS ' 

* AVAILABLE TO BE SENT AND THE NUMBER OF PAYING CUSTOMERS TO GO CBOTR ■ 
FULL-FARE AND* DI SCOUNT) , THEN ASK HOW MANY TRUCKS ARE TO "BE SENT- 
CUSTOMERS WILL BE/' ASSIGNED TO TRUCKS Af THE BEST INCOME RATE. 

/ 

THERE WILL BE SEVERAL IDENTICAL RENTAL COMPANIES, NAMED RENT1, RENT2, J 
RENT 3, E>TC. YOU/ CAN CHOOSE TO BE ANY ONE OF /: THEM. ALSO, YOU CAN DIAL 
MESSAGES TO ANY/OTHER COMPANY BY NAME CUSING CALO • MAYBE. JjDU CAN 
■STRIKE A BARGAIN OF SOME KIND , W*JH AN'OTHER COMPANY THROUGH AN EXCHANGE 
• OF MESSAGES. DON'T WAIT TOCLLONG THOUGH TO DECIDE HOW MANY TRUCKS TO 
'* SEND AFTER YOU HAVE CHOSEN A ROUTE. BECAUSE ANOTHER COMPANY MI GHT GRAB 
THE- PAYING CUSTOMERS FIRST. HERE GOES. 

* ■ * > 
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VHI QH^ COMPANY D<J YOU WANT TO BE? 

1) - RENT1 

2) "- RENT2 

3) - RENT 3 • 

4) - RENT4 * " 

*3 

TRANSACTION? 

'< 

*NEi-PROFITS 

if :' i 

COMPANY 'EARNINGS 



R.ENT1 


S 


;o 


RE.NT2 


.S *' 


0 


REi\'T3 


s 


0 


RENT4 


s 


0 

* 



, COMPANY T ERMI NAL 

{zzzzz-- , 

, RENTt*. 0 

RENT2 0 '/ 

//' RENT3 1 

//' TCENT4 0 

TRANSACTION? 

*TRTJUK5~~~ ' 



CITY AVBL. 

SEA '20 ) • 



PO 15 
SF '35 
LA p 50 



ENROUTE 

b 

o "' 

0 \ 
0v 



TRANSACTION^ 
♦ NET 

COMPANY EARN! 




RENT1 


* S 




RENT2 


S 


/• o 


RENT 3 


t 

• ■ S 




RENT4 


V*- 

s 


0 



•V 



TRANSACTION? 
*LOS^feA ? 

IF YOU ffeANT LOS ANGELES* TYPE • • ^ 
*LA SEA \ " A . ' ' • 

50 TRUCKS AVAILABLE. 11 FULL-FARE AND 5 DISCOUNT CUSTOMERS ARE READY TO 
GO. HOV/ MANY TRUCKS DO Y OH- WANT TO SE&D? - * 

*n * • v 

TRANSACTION? 

' - - * 

*LA PR ' * ~ . * ' f 

* y 

#LA ?0 ' 

39 TRUCKS* AVAILABLE. 2 FULL^ARE AN9*2 DISCOUNT CUSTOMERS ARE REA^Y TO 
GO! HOV; MANY TRUCKS • DCi YOU WANT TO SEND? ' 

TRANSACTION? 
^RUCKS 

CITY AVBL. ENROUTE 



SEA 


20 


11 . 




PO - 


15 


2 




— 


- r ^3'5"~ 


0, » 




LA 


37 


0 





TRANSACTION? • 

9 

0 

^SF S E A « 

35 TRUCKS AVAILABLE. 3 FULL-FARE AND S DISCOUNT CUSTOMERS ARE READY TO 
GO. HOV; MANY TRUCKS DO YOU WANT. TO SEND?' 

c 

* t, • " » 

*3 • . 

TRANSACTION?* / 

♦TRUCKS 

V * * * • 

CITY AVBL. ENROUTE 



\ 



SEA 31 , 3 

P? 17 0 

SF 32 0 

LA,, 3? 
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TRANSACTION? 



*SEA SF « / 

34 TRUCKS AVAILABLE. 3 FULL-FARE AND 6 DISCOUNT CUSTOMERS ARE READY TO 
Gb. HOW MANY TRUCKS DO YOU WANT TO. SEND? • 



*3 

TRANSACTION? 



. *SEA LA / 

31 TRUCKS AVAILABLE. 1 FULL-FARE AND 12 DISCOUNT CUSTOMERS ARE READY* TO 
GO. HOW MANY TRUCKS DO YOU WANT TO SEND? * 

*1 , 

TRANSACTION? 

*5EA LA » « - • * ' * 

30 TRUCKS AVAILABLE. 0 FULL-FARE AND 12 DISCOUNT .CUSTOMERS ARE READY TO 
GO. HOV: MANY TRUCKS DO Y<jU WAiVT TO SEND? 

*0 . * . 

TRANSACTION? • 

*P0, LA 

17 TRUCKS AVAILABLE. 3 FULL-FARE AND 10 DISCOUNT CUSTOMERS ARE READY TO 
GO. HOW .MANY JRtJCKS DO YOU WANT TO SEND? 



*3 



TRANSACTION? * 
*SEA LA * 

30 TRUCKS AVAILABLE. 0 FULL-FARE AND 12 DISCOUNT CUSTOMERS ARE READY TO 
GO. HOW MANY TRUCKS DOi YOU WANT- TO SEND? 



*12 

TRANSACTION? 




J* 



*P0 LA • 

14 TRUCKS. AVAILABLE^ 4 FULL-FARE AND, 1,5 DISCOUNT CUSTOMERS ARE READY TO 
GO. HOW MANY TRUCKS DO Y^U WANT JO* SEND? 



*4 



- 7S - 



9 

FRir. 



81 



\^TRAN< 



.TRANSACTION? , ; 

♦TRUCKS \ 

CLTY AVBL~ JSNROUTE > 4' 
. r 

>SEA .18^ 0 
• PO • 10 • / 0 • * \ 
•SF, 35 . '/v.? 

LA * 41 > M*6 

TftANSACTI/jN? * fc 

*> . *M8\iQ+35*4i + iV,^: 

. 1^0 \ / * 




* tLA SEA *\ V ' \ 

57 TRUCKS AVAILABLE, ft) VuLL-FARE AND 13 DISCOJJNT' CUSTOMERS ARE READY * • 
TO GO." HOW MANY TRUCKS DO, Yf/& WANT TO SEND? • , 



• v.- ' <v 



. *10 

. TRANSACTION? ^ ' . 9 

*SF SEA ' » * « \ 

35 TRUCKS AVAILABLE. 5* FULL-FARE AND 28 " D| SCOUNP CUSTOMERS, ARE READY TO 



GO* HOW MANY TRUCKS DO YOU WANT TO SEND? ^ 



.3* - , f^k .. 

TRANSACTION? " " 5 V 



*LA S'F 

\4 7 TRUCKS AVAILABLE* ,18 FULL^FARE AND 48 DISCOUNT CUSTOMERS ARE READY 
TO GO* HOW MANY TRUCKS DO YOIJ WANT TO SEND? * 4 % 4 * 



*18 ' 

TRANSACTION? 

*NET ' / 

COMPANY 'EARNINGS* 



# 



RENTl S 0 - 

RENT 2 , # ■ 0 . ? \\ ' 

RENT3/ 5 . 6980- « .« 
RENT4 v S, . . 0. ' 



v. 



TRANSACTION? 
♦ TRUCKS- 




„CITX 


AVBL. 


. ENROJJTE . . * 








SfeA 


* 18 •'. 


43 . " ' 


PQ \ 


Mo * 




SF 


•a' 


* 18 




29 


'i 0 






.• * 





7 



TRANSACTION? 



\ - 



*SEA LA • • • - 

% 61 TRUCKS AVAILABLE*/ 2 FULL --FARE AND 16 DISCOUNT CUSTOMERS ARE* READY TO ' 
G<5. HOtv MANY "TRUCKS DO YOU IvANT TO SEND? 1 1 



~*l-8 S 

TRANSACT I ON# 
« 

-+SEA ,SF* 



1 



43TRSCKS AVAILABLE. 3 FULLrFARt AND 10 DISCOUNT CUSTOMERS ARE rfEADY TO 
GO. HOV; MANY TRUCKS DO YOU WANT TO SEND? * . 

♦ • * « ■ • 



*13 

TRANSACTION? 



*SF, LA • ' ( • • * t 

20 TRUCKS AVAILABLE, 'l 5 FULL- FARE AND 54 DISCOUNT CUSTOMERS A*RE READYt 
TO GO. r HOvJ MANY TRUCKS' DO YOU WANT TO SE&D? 



v 



*20 

TRANSACTION? 
f TRUCKS 



CITY 


"AVBL.. 


EN ROUTE ' 


• 


- SEA 


, : 






# r ?ty 








SF 


• 6 . 






LA 


* -89 . 










•' .V s 






















4 







ft. 



\ 



ERIC ; V. 



m 

83 r 



TRANSACTION? 



*LA SF 



7 



6*7 TRUCKS .AVAILABLE. 7 FULL-FARE AND 75 DISCOUNT CUSTOMERS ARE READY TO 



GO. HOU" MANY TRUCKS, DO YOU WANT TO SEND? 




m 

.TRANSACTION? 
*TRuCKS 

4 

CITY AVBL. . ENROUTE 

* SEA "^30 * : v • * ' ^ * 

*?0 10 
SF 

, . La , .^50 
transaction? \ ' * . ^ 

% * ^ 

*NET . *. * 

? * CW<?ANY EARNINGS 

RENT1 *S ; 0- 

RENT 2 * S . . 0 

RENT 3 ' V 100G0 

R£NT4 S 0 

• TRAXSACTI'ON? 



v 



: / 



/ 



i 

\ ■ 



\ -79- • : • ",V 



